<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>RE: [seam-dev] Implementing REQUIRES_NEW for seam transaction management</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2>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.<BR>
<BR>
I'm not going to write app server specific components and documentation until after I have got the rest of the patch complete.<BR>
<BR>
<BR>
Stuart<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Pete Muir [<A HREF="mailto:pmuir@redhat.com">mailto:pmuir@redhat.com</A>]<BR>
Sent: Thu 3/09/2009 12:58 AM<BR>
To: Denis Forveille<BR>
Cc: Stuart Douglas; seam-dev@lists.jboss.org<BR>
Subject: Re: [seam-dev] Implementing REQUIRES_NEW for seam transaction management<BR>
<BR>
<BR>
On 2 Sep 2009, at 09:44, Denis Forveille wrote:<BR>
<BR>
> Stuart,<BR>
><BR>
> I don't agree with the proposed patch as it assume that the<BR>
> "TransactionManager" is exposed and accessible to the applications and<BR>
> is bound in JNDI (you assume "java:/TransactionManager" as the<BR>
> default name)<BR>
><BR>
> As said before, this is not part of the J2EE contract for the AS to<BR>
> expose their TransactionManager and some do not, like WebSphere.<BR>
<BR>
This is correct, and has not been fixed in Java EE.<BR>
<BR>
If you really need a portable way to get the TM, you would need to <BR>
make this a pluggable service provider.<BR>
<BR>
><BR>
> To my knowledge, there is no "standard" way to get this object in J2EE<BR>
> and every AS may have their way, some may not exposes it at all.<BR>
><BR>
> If you want to know what WebSphere officially exposes to users<BR>
> concerning transactions management, , you should read this article in<BR>
> the WebSphere information center :<BR>
> <A HREF="http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.express.doc/info/exp/ae/cjta_extjta.html">http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.express.doc/info/exp/ae/cjta_extjta.html</A><BR>
><BR>
> One "easy" solution could be to declare that this functionality is<BR>
> only available to AS that expose their TransactionManager via JNDI,<BR>
> but thsi is not very elegant for a framework like Seam to do that<BR>
> IMHO.<BR>
><BR>
> Denis<BR>
><BR>
><BR>
><BR>
> 2009/9/2 Stuart Douglas <stuart@baileyroberts.com.au>:<BR>
>> I have attached the first version of the REQUIRES_NEW patch to<BR>
>> JBSEAM-4391.<BR>
>><BR>
>><BR>
>> It seems to work ok, however I have not yet created the tests for it,<BR>
>> and at the moment I have only supplied a simple transaction manager <BR>
>> that<BR>
>> looks up the JTA TransactionManager from JNDI.<BR>
>><BR>
>> I do however have a few questions about the best way to handle<BR>
>> persistence context propagation. The SMPC does not properly support<BR>
>> REQUIRES_NEW on EJB's (you should use @PersistenceContext instead), <BR>
>> and<BR>
>> it also will not properly support REQUIRES_NEW on seam components.<BR>
>><BR>
>> This is a much bigger problem for seam components, as there is not<BR>
>> direct equivalent of @PersistenceContext. I have a few solutions in<BR>
>> mind:<BR>
>><BR>
>> 1) When suspending the transaction pull all persistence contexts <BR>
>> out of<BR>
>> all scopes and store them in a map, when the original transaction<BR>
>> resumes put them back (there is more to it that this, like do we <BR>
>> flush<BR>
>> the PC's that are created in the new transaction).<BR>
>><BR>
>> 2) Place some kind of warning in the log whenever a user accesses a<BR>
>> persistence context that they shouldn't. This would probably require<BR>
>> hacking up the ManagedPersistenceContext class, and would not really<BR>
>> help the use get hold of an EntityManager they are allowed to use.<BR>
>><BR>
>> 3) Do nothing, but document this in the manual. The user would have <BR>
>> to<BR>
>> create their own entity managers by getting hold of an<BR>
>> EntityManagerFactory.<BR>
>><BR>
>><BR>
>> Comments?<BR>
>><BR>
>> Stuart<BR>
>><BR>
>><BR>
>><BR>
>><BR>
>><BR>
>><BR>
>> On Mon, 2009-08-31 at 14:36 -0400, Dan Allen wrote:<BR>
>>> On Wed, Aug 26, 2009 at 8:55 PM, Stuart Douglas<BR>
>>> <stuart@baileyroberts.com.au> wrote:<BR>
>>> I would like to implement REQUIRES_NEW as a transaction type<BR>
>>> for the<BR>
>>> @Transactional annotation. My basic plan is:<BR>
>>><BR>
>>> - Create a TransactionManager component that can be <BR>
>>> installed<BR>
>>> into<BR>
>>> components.xml, and give the option to configure the JNDI<BR>
>>> location of<BR>
>>> the JTA TransactionManager.<BR>
>>><BR>
>>> - modify the Work.workInTransaction method to check if the<BR>
>>> existing<BR>
>>> transaction need to be suspended, as if so use the<BR>
>>> TransactionManager<BR>
>>> component to suspend and resume the transaction.<BR>
>>><BR>
>>> I can't help thinking that there is some problem with this<BR>
>>> approach,<BR>
>>> otherwise someone else would have already done it.<BR>
>>><BR>
>>> Try it, create some tests and if it works, prove it.<BR>
>>><BR>
>>><BR>
>>><BR>
>>> I also know that TransactionManager is not supposed to be <BR>
>>> used<BR>
>>> by the<BR>
>>> application, does anyone know if this will cause problems?<BR>
>>><BR>
>>> Spring has been doing this for a long time. It's of course app <BR>
>>> server<BR>
>>> dependent, but the general feeling is that using it is so common to<BR>
>>> consider it a public API.<BR>
>>><BR>
>>><BR>
>>><BR>
>>> I would also like to implement the ability to control seam<BR>
>>> global<BR>
>>> transactions based on a flag in pages.xml, so they can be<BR>
>>> disabled for<BR>
>>> specific views. Would anyone have any objections to this?<BR>
>>><BR>
>>> I've always been in favor of this idea.<BR>
>>><BR>
>>> -Dan<BR>
>>><BR>
>>><BR>
>>> --<BR>
>>> Dan Allen<BR>
>>> Senior Software Engineer, Red Hat | Author of Seam in Action<BR>
>>> Registered Linux User #231597<BR>
>>><BR>
>>> <A HREF="http://mojavelinux.com">http://mojavelinux.com</A><BR>
>>> <A HREF="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</A><BR>
>>> <A HREF="http://in.relation.to/Bloggers/Dan">http://in.relation.to/Bloggers/Dan</A><BR>
>> _______________________________________________<BR>
>> seam-dev mailing list<BR>
>> seam-dev@lists.jboss.org<BR>
>> <A HREF="https://lists.jboss.org/mailman/listinfo/seam-dev">https://lists.jboss.org/mailman/listinfo/seam-dev</A><BR>
>><BR>
><BR>
> _______________________________________________<BR>
> seam-dev mailing list<BR>
> seam-dev@lists.jboss.org<BR>
> <A HREF="https://lists.jboss.org/mailman/listinfo/seam-dev">https://lists.jboss.org/mailman/listinfo/seam-dev</A><BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>