I was just trying to give you an easy option. It has worked well for me. YMMV.
Tony > -----Original Message----- > From: Charlouze [mailto:m...@charlouze.com] > Sent: Thursday, September 25, 2014 9:56 AM > To: Tapestry users > Subject: Re: Tapestry-jpa commitAfter advisor problem > > @Chris: I'm using 5.4 and I don't really want to use spring... I'm > using tapestry-ioc for my logic/business layer and i'd like it to stay > that way. > Even though I already used spring for some time, I think it'll be more > difficult for new junior devs to get into the code. > I'm thinking about writing a more "clever" advisor for @transactional > that will fulfill my simple needs. > > @Tony: I'm too much a fan of "separation of concerns" to do what your > are telling me ;) > > > > 2014-09-25 15:51 GMT+02:00 Tony Nelson <tnel...@starpoint.com>: > > > 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 > > 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.