[seam-dev] Implementing REQUIRES_NEW for seam transaction management

[Pete Muir]

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