You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Charlouze <me...@charlouze.com> on 2014/09/25 15:08:11 UTC
Tapestry-jpa commitAfter advisor problem
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.
Re: Tapestry-jpa commitAfter advisor problem
Posted by Charlouze <me...@charlouze.com>.
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 <tn...@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:me@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 <tn...@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:chris@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 <me...@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 <du...@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 <me...@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-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@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.
>
RE: Tapestry-jpa commitAfter advisor problem
Posted by Tony Nelson <tn...@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:me@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 <tn...@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:chris@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 <me...@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 <du...@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 <me...@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-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@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.
Re: Tapestry-jpa commitAfter advisor problem
Posted by Charlouze <me...@charlouze.com>.
@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 <tn...@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:chris@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 <me...@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 <du...@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 <me...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
RE: Tapestry-jpa commitAfter advisor problem
Posted by Tony Nelson <tn...@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:chris@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 <me...@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 <du...@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 <me...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-jpa commitAfter advisor problem
Posted by Chris Mylonas <ch...@opencsta.org>.
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 <me...@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 <du...@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 <me...@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.
> > >
> >
>
Re: Tapestry-jpa commitAfter advisor problem
Posted by Charlouze <me...@charlouze.com>.
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 <du...@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 <me...@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.
> >
>
Re: Tapestry-jpa commitAfter advisor problem
Posted by Dusko Jovanovski <du...@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 <me...@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.
>