Implementing REQUIRES_NEW for seam transaction management
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
Implementing REQUIRES_NEW for seam transaction management
by Stuart Douglas
::
Rate this Message:
I would like to implement REQUIRES_NEW as a transaction type for the
@Transactional annotation. My basic plan is: - Create a TransactionManager component that can be installed into components.xml, and give the option to configure the JNDI location of the JTA TransactionManager. - modify the Work.workInTransaction method to check if the existing transaction need to be suspended, as if so use the TransactionManager component to suspend and resume the transaction. I can't help thinking that there is some problem with this approach, otherwise someone else would have already done it. I also know that TransactionManager is not supposed to be used by the application, does anyone know if this will cause problems? I would also like to implement the ability to control seam global transactions based on a flag in pages.xml, so they can be disabled for specific views. Would anyone have any objections to this? Stuart _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Implementing REQUIRES_NEW for seam transaction management
by Dan Allen (mojavelinux)
::
Rate this Message:
On Wed, Aug 26, 2009 at 8:55 PM, Stuart Douglas <stuart@...> wrote: I would like to implement REQUIRES_NEW as a transaction type for the Try it, create some tests and if it works, prove it.
Spring has been doing this for a long time. It's of course app server dependent, but the general feeling is that using it is so common to consider it a public API.
I've always been in favor of this idea. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Implementing REQUIRES_NEW for seam transaction management
by Denis Forveille
::
Rate this Message:
2009/8/31 Dan Allen <dan.j.allen@...>:
> On Wed, Aug 26, 2009 at 8:55 PM, Stuart Douglas > <stuart@...> wrote: >> >> I would like to implement REQUIRES_NEW as a transaction type for the >> @Transactional annotation. My basic plan is: >> >> - Create a TransactionManager component that can be installed into >> components.xml, and give the option to configure the JNDI location of >> the JTA TransactionManager. >> >> - modify the Work.workInTransaction method to check if the existing >> transaction need to be suspended, as if so use the TransactionManager >> component to suspend and resume the transaction. >> >> I can't help thinking that there is some problem with this approach, >> otherwise someone else would have already done it. > > Try it, create some tests and if it works, prove it. > >> >> I also know that TransactionManager is not supposed to be used by the >> application, does anyone know if this will cause problems? > > Spring has been doing this for a long time. It's of course app server > dependent, but the general feeling is that using it is so common to consider > it a public API. > not part of the J2EE contract. For hibernate, have a look at the org.hibernate.transaction.WebSphereExtendedJTATransactionLookup class to have an idea how they access it (in a non supported way..) I don't know how Spring did it, maybe look at org.springframework.transaction.jta.WebSphereUowTransactionManager >> >> I would also like to implement the ability to control seam global >> transactions based on a flag in pages.xml, so they can be disabled for >> specific views. Would anyone have any objections to this? > > I've always been in favor of this idea. > > -Dan > > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://in.relation.to/Bloggers/Dan > > _______________________________________________ > seam-dev mailing list > seam-dev@... > https://lists.jboss.org/mailman/listinfo/seam-dev > > seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Implementing REQUIRES_NEW for seam transaction management
by Stuart Douglas
::
Rate this Message:
I have attached the first version of the REQUIRES_NEW patch to
JBSEAM-4391. It seems to work ok, however I have not yet created the tests for it, and at the moment I have only supplied a simple transaction manager that looks up the JTA TransactionManager from JNDI. I do however have a few questions about the best way to handle persistence context propagation. The SMPC does not properly support REQUIRES_NEW on EJB's (you should use @PersistenceContext instead), and it also will not properly support REQUIRES_NEW on seam components. This is a much bigger problem for seam components, as there is not direct equivalent of @PersistenceContext. I have a few solutions in mind: 1) When suspending the transaction pull all persistence contexts out of all scopes and store them in a map, when the original transaction resumes put them back (there is more to it that this, like do we flush the PC's that are created in the new transaction). 2) Place some kind of warning in the log whenever a user accesses a persistence context that they shouldn't. This would probably require hacking up the ManagedPersistenceContext class, and would not really help the use get hold of an EntityManager they are allowed to use. 3) Do nothing, but document this in the manual. The user would have to create their own entity managers by getting hold of an EntityManagerFactory. Comments? Stuart On Mon, 2009-08-31 at 14:36 -0400, Dan Allen wrote: > On Wed, Aug 26, 2009 at 8:55 PM, Stuart Douglas > <stuart@...> wrote: > I would like to implement REQUIRES_NEW as a transaction type > for the > @Transactional annotation. My basic plan is: > > - Create a TransactionManager component that can be installed > into > components.xml, and give the option to configure the JNDI > location of > the JTA TransactionManager. > > - modify the Work.workInTransaction method to check if the > existing > transaction need to be suspended, as if so use the > TransactionManager > component to suspend and resume the transaction. > > I can't help thinking that there is some problem with this > approach, > otherwise someone else would have already done it. > > Try it, create some tests and if it works, prove it. > > > > I also know that TransactionManager is not supposed to be used > by the > application, does anyone know if this will cause problems? > > Spring has been doing this for a long time. It's of course app server > dependent, but the general feeling is that using it is so common to > consider it a public API. > > > > I would also like to implement the ability to control seam > global > transactions based on a flag in pages.xml, so they can be > disabled for > specific views. Would anyone have any objections to this? > > I've always been in favor of this idea. > > -Dan > > > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://in.relation.to/Bloggers/Dan seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Implementing REQUIRES_NEW for seam transaction management
by Denis Forveille
::
Rate this Message:
Stuart,
I don't agree with the proposed patch as it assume that the "TransactionManager" is exposed and accessible to the applications and is bound in JNDI (you assume "java:/TransactionManager" as the default name) As said before, this is not part of the J2EE contract for the AS to expose their TransactionManager and some do not, like WebSphere. To my knowledge, there is no "standard" way to get this object in J2EE and every AS may have their way, some may not exposes it at all. If you want to know what WebSphere officially exposes to users concerning transactions management, , you should read this article in the WebSphere information center : http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.express.doc/info/exp/ae/cjta_extjta.html One "easy" solution could be to declare that this functionality is only available to AS that expose their TransactionManager via JNDI, but thsi is not very elegant for a framework like Seam to do that IMHO. Denis 2009/9/2 Stuart Douglas <stuart@...>: > I have attached the first version of the REQUIRES_NEW patch to > JBSEAM-4391. > > > It seems to work ok, however I have not yet created the tests for it, > and at the moment I have only supplied a simple transaction manager that > looks up the JTA TransactionManager from JNDI. > > I do however have a few questions about the best way to handle > persistence context propagation. The SMPC does not properly support > REQUIRES_NEW on EJB's (you should use @PersistenceContext instead), and > it also will not properly support REQUIRES_NEW on seam components. > > This is a much bigger problem for seam components, as there is not > direct equivalent of @PersistenceContext. I have a few solutions in > mind: > > 1) When suspending the transaction pull all persistence contexts out of > all scopes and store them in a map, when the original transaction > resumes put them back (there is more to it that this, like do we flush > the PC's that are created in the new transaction). > > 2) Place some kind of warning in the log whenever a user accesses a > persistence context that they shouldn't. This would probably require > hacking up the ManagedPersistenceContext class, and would not really > help the use get hold of an EntityManager they are allowed to use. > > 3) Do nothing, but document this in the manual. The user would have to > create their own entity managers by getting hold of an > EntityManagerFactory. > > > Comments? > > Stuart > > > > > > > On Mon, 2009-08-31 at 14:36 -0400, Dan Allen wrote: >> On Wed, Aug 26, 2009 at 8:55 PM, Stuart Douglas >> <stuart@...> wrote: >> I would like to implement REQUIRES_NEW as a transaction type >> for the >> @Transactional annotation. My basic plan is: >> >> - Create a TransactionManager component that can be installed >> into >> components.xml, and give the option to configure the JNDI >> location of >> the JTA TransactionManager. >> >> - modify the Work.workInTransaction method to check if the >> existing >> transaction need to be suspended, as if so use the >> TransactionManager >> component to suspend and resume the transaction. >> >> I can't help thinking that there is some problem with this >> approach, >> otherwise someone else would have already done it. >> >> Try it, create some tests and if it works, prove it. >> >> >> >> I also know that TransactionManager is not supposed to be used >> by the >> application, does anyone know if this will cause problems? >> >> Spring has been doing this for a long time. It's of course app server >> dependent, but the general feeling is that using it is so common to >> consider it a public API. >> >> >> >> I would also like to implement the ability to control seam >> global >> transactions based on a flag in pages.xml, so they can be >> disabled for >> specific views. Would anyone have any objections to this? >> >> I've always been in favor of this idea. >> >> -Dan >> >> >> -- >> Dan Allen >> Senior Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> http://in.relation.to/Bloggers/Dan > _______________________________________________ > seam-dev mailing list > seam-dev@... > https://lists.jboss.org/mailman/listinfo/seam-dev > _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Implementing REQUIRES_NEW for seam transaction management
by Pete Muir-2
::
Rate this Message:
On 2 Sep 2009, at 09:44, Denis Forveille wrote: > Stuart, > > I don't agree with the proposed patch as it assume that the > "TransactionManager" is exposed and accessible to the applications and > is bound in JNDI (you assume "java:/TransactionManager" as the > default name) > > As said before, this is not part of the J2EE contract for the AS to > expose their TransactionManager and some do not, like WebSphere. This is correct, and has not been fixed in Java EE. If you really need a portable way to get the TM, you would need to make this a pluggable service provider. > > To my knowledge, there is no "standard" way to get this object in J2EE > and every AS may have their way, some may not exposes it at all. > > If you want to know what WebSphere officially exposes to users > concerning transactions management, , you should read this article in > the WebSphere information center : > http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.express.doc/info/exp/ae/cjta_extjta.html > > One "easy" solution could be to declare that this functionality is > only available to AS that expose their TransactionManager via JNDI, > but thsi is not very elegant for a framework like Seam to do that > IMHO. > > Denis > > > > 2009/9/2 Stuart Douglas <stuart@...>: >> I have attached the first version of the REQUIRES_NEW patch to >> JBSEAM-4391. >> >> >> It seems to work ok, however I have not yet created the tests for it, >> and at the moment I have only supplied a simple transaction manager >> that >> looks up the JTA TransactionManager from JNDI. >> >> I do however have a few questions about the best way to handle >> persistence context propagation. The SMPC does not properly support >> REQUIRES_NEW on EJB's (you should use @PersistenceContext instead), >> and >> it also will not properly support REQUIRES_NEW on seam components. >> >> This is a much bigger problem for seam components, as there is not >> direct equivalent of @PersistenceContext. I have a few solutions in >> mind: >> >> 1) When suspending the transaction pull all persistence contexts >> out of >> all scopes and store them in a map, when the original transaction >> resumes put them back (there is more to it that this, like do we >> flush >> the PC's that are created in the new transaction). >> >> 2) Place some kind of warning in the log whenever a user accesses a >> persistence context that they shouldn't. This would probably require >> hacking up the ManagedPersistenceContext class, and would not really >> help the use get hold of an EntityManager they are allowed to use. >> >> 3) Do nothing, but document this in the manual. The user would have >> to >> create their own entity managers by getting hold of an >> EntityManagerFactory. >> >> >> Comments? >> >> Stuart >> >> >> >> >> >> >> On Mon, 2009-08-31 at 14:36 -0400, Dan Allen wrote: >>> On Wed, Aug 26, 2009 at 8:55 PM, Stuart Douglas >>> <stuart@...> wrote: >>> I would like to implement REQUIRES_NEW as a transaction type >>> for the >>> @Transactional annotation. My basic plan is: >>> >>> - Create a TransactionManager component that can be >>> installed >>> into >>> components.xml, and give the option to configure the JNDI >>> location of >>> the JTA TransactionManager. >>> >>> - modify the Work.workInTransaction method to check if the >>> existing >>> transaction need to be suspended, as if so use the >>> TransactionManager >>> component to suspend and resume the transaction. >>> >>> I can't help thinking that there is some problem with this >>> approach, >>> otherwise someone else would have already done it. >>> >>> Try it, create some tests and if it works, prove it. >>> >>> >>> >>> I also know that TransactionManager is not supposed to be >>> used >>> by the >>> application, does anyone know if this will cause problems? >>> >>> Spring has been doing this for a long time. It's of course app >>> server >>> dependent, but the general feeling is that using it is so common to >>> consider it a public API. >>> >>> >>> >>> I would also like to implement the ability to control seam >>> global >>> transactions based on a flag in pages.xml, so they can be >>> disabled for >>> specific views. Would anyone have any objections to this? >>> >>> I've always been in favor of this idea. >>> >>> -Dan >>> >>> >>> -- >>> Dan Allen >>> Senior Software Engineer, Red Hat | Author of Seam in Action >>> Registered Linux User #231597 >>> >>> http://mojavelinux.com >>> http://mojavelinux.com/seaminaction >>> http://in.relation.to/Bloggers/Dan >> _______________________________________________ >> seam-dev mailing list >> seam-dev@... >> https://lists.jboss.org/mailman/listinfo/seam-dev >> > > _______________________________________________ > seam-dev mailing list > seam-dev@... > https://lists.jboss.org/mailman/listinfo/seam-dev _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Implementing REQUIRES_NEW for seam transaction management
by Stuart Douglas
::
Rate this Message:
It is pluggable, you create a component that extends SeamTransactionManager and install it over the top of the default implementation, or if the TransactionManager is in jndi but in a different location then that can be configured through components.xml as well. _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Implementing REQUIRES_NEW for seam transaction management
by Stuart Douglas
::
Rate this Message:
I have attached a new patch to the issue that contains some integration tests and prevents the propagation of the seam managed persistence context into the new transaction. Stuart On Thu, 2009-09-03 at 06:55 +1000, Stuart Douglas wrote: > > It is pluggable, you create a component that extends > SeamTransactionManager and install it over the top of the default > implementation, or if the TransactionManager is in jndi but in a > different location then that can be configured through components.xml > as well. > > I'm not going to write app server specific components and > documentation until after I have got the rest of the patch complete. > > > Stuart > > > -----Original Message----- > From: Pete Muir [mailto:pmuir@...] > Sent: Thu 3/09/2009 12:58 AM > To: Denis Forveille > Cc: Stuart Douglas; seam-dev@... > Subject: Re: [seam-dev] Implementing REQUIRES_NEW for seam transaction > management > > > On 2 Sep 2009, at 09:44, Denis Forveille wrote: > > > Stuart, > > > > I don't agree with the proposed patch as it assume that the > > "TransactionManager" is exposed and accessible to the applications > and > > is bound in JNDI (you assume "java:/TransactionManager" as the > > default name) > > > > As said before, this is not part of the J2EE contract for the AS to > > expose their TransactionManager and some do not, like WebSphere. > > This is correct, and has not been fixed in Java EE. > > If you really need a portable way to get the TM, you would need to > make this a pluggable service provider. > > > > > To my knowledge, there is no "standard" way to get this object in > J2EE > > and every AS may have their way, some may not exposes it at all. > > > > If you want to know what WebSphere officially exposes to users > > concerning transactions management, , you should read this article > in > > the WebSphere information center : > > > http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.express.doc/info/exp/ae/cjta_extjta.html > > > > One "easy" solution could be to declare that this functionality is > > only available to AS that expose their TransactionManager via JNDI, > > but thsi is not very elegant for a framework like Seam to do that > > IMHO. > > > > Denis > > > > > > > > 2009/9/2 Stuart Douglas <stuart@...>: > >> I have attached the first version of the REQUIRES_NEW patch to > >> JBSEAM-4391. > >> > >> > >> It seems to work ok, however I have not yet created the tests for > it, > >> and at the moment I have only supplied a simple transaction > manager > >> that > >> looks up the JTA TransactionManager from JNDI. > >> > >> I do however have a few questions about the best way to handle > >> persistence context propagation. The SMPC does not properly support > >> REQUIRES_NEW on EJB's (you should use @PersistenceContext > instead), > >> and > >> it also will not properly support REQUIRES_NEW on seam components. > >> > >> This is a much bigger problem for seam components, as there is not > >> direct equivalent of @PersistenceContext. I have a few solutions in > >> mind: > >> > >> 1) When suspending the transaction pull all persistence contexts > >> out of > >> all scopes and store them in a map, when the original transaction > >> resumes put them back (there is more to it that this, like do we > >> flush > >> the PC's that are created in the new transaction). > >> > >> 2) Place some kind of warning in the log whenever a user accesses a > >> persistence context that they shouldn't. This would probably > require > >> hacking up the ManagedPersistenceContext class, and would not > really > >> help the use get hold of an EntityManager they are allowed to use. > >> > >> 3) Do nothing, but document this in the manual. The user would > have > >> to > >> create their own entity managers by getting hold of an > >> EntityManagerFactory. > >> > >> > >> Comments? > >> > >> Stuart > >> > >> > >> > >> > >> > >> > >> On Mon, 2009-08-31 at 14:36 -0400, Dan Allen wrote: > >>> On Wed, Aug 26, 2009 at 8:55 PM, Stuart Douglas > >>> <stuart@...> wrote: > >>> I would like to implement REQUIRES_NEW as a transaction > type > >>> for the > >>> @Transactional annotation. My basic plan is: > >>> > >>> - Create a TransactionManager component that can be > >>> installed > >>> into > >>> components.xml, and give the option to configure the JNDI > >>> location of > >>> the JTA TransactionManager. > >>> > >>> - modify the Work.workInTransaction method to check if the > >>> existing > >>> transaction need to be suspended, as if so use the > >>> TransactionManager > >>> component to suspend and resume the transaction. > >>> > >>> I can't help thinking that there is some problem with this > >>> approach, > >>> otherwise someone else would have already done it. > >>> > >>> Try it, create some tests and if it works, prove it. > >>> > >>> > >>> > >>> I also know that TransactionManager is not supposed to be > >>> used > >>> by the > >>> application, does anyone know if this will cause problems? > >>> > >>> Spring has been doing this for a long time. It's of course app > >>> server > >>> dependent, but the general feeling is that using it is so common > to > >>> consider it a public API. > >>> > >>> > >>> > >>> I would also like to implement the ability to control seam > >>> global > >>> transactions based on a flag in pages.xml, so they can be > >>> disabled for > >>> specific views. Would anyone have any objections to this? > >>> > >>> I've always been in favor of this idea. > >>> > >>> -Dan > >>> > >>> > >>> -- > >>> Dan Allen > >>> Senior Software Engineer, Red Hat | Author of Seam in Action > >>> Registered Linux User #231597 > >>> > >>> http://mojavelinux.com > >>> http://mojavelinux.com/seaminaction > >>> http://in.relation.to/Bloggers/Dan > >> _______________________________________________ > >> seam-dev mailing list > >> seam-dev@... > >> https://lists.jboss.org/mailman/listinfo/seam-dev > >> > > > > _______________________________________________ > > seam-dev mailing list > > seam-dev@... > > https://lists.jboss.org/mailman/listinfo/seam-dev > > > > > _______________________________________________ > seam-dev mailing list > seam-dev@... > https://lists.jboss.org/mailman/listinfo/seam-dev seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
| Free embeddable forum powered by Nabble | Forum Help |
