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.
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
I'm not going to write app server specific components and
documentation until after I have got the rest of the patch complete.
From: Pete Muir [mailto:email@example.com]
Sent: Thu 3/09/2009 12:58 AM
To: Denis Forveille
Cc: Stuart Douglas; seam-dev(a)lists.jboss.org
Subject: Re: [seam-dev] Implementing REQUIRES_NEW for seam transaction
On 2 Sep 2009, at 09:44, Denis Forveille wrote:
> I don't agree with the proposed patch as it assume that the
> "TransactionManager" is exposed and accessible to the applications
> 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
> 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
> the WebSphere information center :
> 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
> 2009/9/2 Stuart Douglas <stuart(a)baileyroberts.com.au>:
>> I have attached the first version of the REQUIRES_NEW patch to
>> It seems to work ok, however I have not yet created the tests for
>> and at the moment I have only supplied a simple transaction
>> 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
>> 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
>> 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
>> 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
>> hacking up the ManagedPersistenceContext class, and would not
>> 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
>> create their own entity managers by getting hold of an
>> On Mon, 2009-08-31 at 14:36 -0400, Dan Allen wrote:
>>> On Wed, Aug 26, 2009 at 8:55 PM, Stuart Douglas
>>> <stuart(a)baileyroberts.com.au> wrote:
>>> I would like to implement REQUIRES_NEW as a transaction
>>> for the
>>> @Transactional annotation. My basic plan is:
>>> - Create a TransactionManager component that can be
>>> components.xml, and give the option to configure the JNDI
>>> location of
>>> the JTA TransactionManager.
>>> - modify the Work.workInTransaction method to check if the
>>> transaction need to be suspended, as if so use the
>>> component to suspend and resume the transaction.
>>> I can't help thinking that there is some problem with this
>>> 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
>>> 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
>>> dependent, but the general feeling is that using it is so common
>>> consider it a public API.
>>> I would also like to implement the ability to control seam
>>> 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 Allen
>>> Senior Software Engineer, Red Hat | Author of Seam in Action
>>> Registered Linux User #231597
>> seam-dev mailing list
> seam-dev mailing list
seam-dev mailing list