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.

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?

On Wed, Aug 26, 2009 at 8:55 PM, Stuart Douglas <stuart(a)baileyroberts.com.au&gt; 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

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.websp... 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(a)baileyroberts.com.au&gt;: > 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(a)baileyroberts.com.au&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

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@redhat.com] Sent: Thu 3/09/2009 12:58 AM To: Denis Forveille Cc: Stuart Douglas; seam-dev(a)lists.jboss.org 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.websp... > > 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(a)baileyroberts.com.au&gt;: >> 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(a)baileyroberts.com.au&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> > > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev