Thx for your quick answer. My method2 can be used in a "stand-alone way" so removing @CommitAfter is not an option. I could get around the problem with another method called by both method 1 and 2 but it'll bring mess to my code having one method that commits the transaction and another one that don't.
If I want a better support of transaction, what should I do then ? 2014-09-25 15:20 GMT+02:00 Dusko Jovanovski <dusk...@gmail.com>: > The @CommitAfter annotation should be used as a convenience for simple > scenarios, it doesn't support nesting. This has been discussed many times > in the past on this mailing list. > For the scenario that you described, I would remove the @CommitAfter > annotation from method2, this way all of the code will be wrapped in a > single transaction. > > On Thu, Sep 25, 2014 at 3:08 PM, Charlouze <m...@charlouze.com> wrote: > > > Hey everyone > > > > Here is my problem : > > > > I have a service (service1) that has a method (method1) which has the > > @CommitAfter annotation in order for tapestry to take care of the > > transaction. > > I have a second service (service2) that has a method (method2) which also > > has the @CommitAfter annotation. > > service2 is injected into service1 and method2 is used by method1. > > > > The problem is method2 commits the transaction even though it is not the > > one that began it. Thus, every modifications made to managed entities > that > > are done after the method2 call in method1 are not commited. > > > > Am i wrong using those services like that or is it the advisor that has a > > wrong behavior ? > > > > Thx in advance, > > Charles. > > >
