[seam-dev] Implementing REQUIRES_NEW for seam transaction management

Wed Sep 2 21:48:56 EDT 2009

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