[seam-dev] Implementing REQUIRES_NEW for seam transaction management

[Denis Forveille]

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 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
>