Sure ... but it's too easy :P I prefer the hard way and i'm going to implement the JTA spec over the night :D
2014-09-25 16:07 GMT+02:00 Tony Nelson <tnel...@starpoint.com>: > 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. >
