For my projected, I moved the @CommitAfter annotations from the database layer, to the web controllers themselves.
Other folks have said that breaks separation of concerns. For my project it was the simplest and most straight forward way of getting tapestry-hibernate to do what was necessary. Tony > -----Original Message----- > From: Chris Mylonas [mailto:ch...@opencsta.org] > Sent: Thursday, September 25, 2014 9:43 AM > To: Tapestry users > Subject: Re: Tapestry-jpa commitAfter advisor problem > > 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. > > > > > > > > > Since 1982, Starpoint Solutions has been a trusted source of human capital and solutions. We are committed to our clients, employees, environment, community and social concerns. We foster an inclusive culture based on trust, respect, honesty and solid performance. Learn more about Starpoint and our social responsibility at http://www.starpoint.com/social_responsibility This email message from Starpoint Solutions LLC is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Opinions, conclusions and other information in this message that do not relate to the official business of Starpoint Solutions shall be understood as neither given nor endorsed by it. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
