[seam-dev] Implementing REQUIRES_NEW for seam transaction management

[Stuart Douglas]

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