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@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@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@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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev