I only know EJB/JPA but I'm sure some people will say Spring. I prototype in tapestry-hibernate because the docs were easier at the time to use than tapestry-jpa, and when I hit nesting problems that's when I switch to using the @EJB annotation.
I need to switch to tapestry-jpa to make my transition smoother :) What version of tapestry are you using? Because I've found I can go further on 5.3.7 than I can on 5.4 when it comes to hitting nesting problems. YMMV As an alternative I'm thinking about giving this object mocking workflow a go without all the transaction stuff - just so I can do my tapestry stuff faster. On Thu, Sep 25, 2014 at 11:30 PM, Charlouze <m...@charlouze.com> wrote: > 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. > > > > > >
