@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 >
