Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mprudhomapache@gmail.com
 designates 66.249.92.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=EEK7ON/2r+Z5XIzjEf5wivl3Bx8K8EYTgWxWhWVeNzf/8F7s0e44Qfo4V77nsOteMtZy6VaNhG+UK6t1kDQy1pTRxjD+CeZoeCJyRWp2goZe5Xw3foTjwsATeICWJZoAUNQKVZG0Qjllxlsiax8Y80tMxxhhMOCGP1ap4tpBqK4=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <89c0c52c0610181443r4fbb163ehfc8f00c7c4248072@mail.gmail.com>
References: <38D03C8F-ED25-477B-B92B-5862ACD34493@apache.org>
 <E9717CEF-F07E-4AE1-9B48-B187653BF381@bea.com>
 <89c0c52c0610181443r4fbb163ehfc8f00c7c4248072@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <DFD361EF-BA1A-45ED-AECC-21EC95ADBC2C@apache.org>
Content-Transfer-Encoding: 7bit
From: Marc Prud'hommeaux <mprudhom@apache.org>
Subject: Re: TransactionManagerFactory and WAS (was: [VOTE] publish openjpa
 0.9.5-incubating podling release)
Date: Wed, 18 Oct 2006 15:39:31 -0700
To: open-jpa-dev@incubator.apache.org
Sender: Marc Prud'hommeaux <mprudhomapache@gmail.com>

Kevin-

On Oct 18, 2006, at 2:43 PM, Kevin Sutter wrote:

> -0
>
> Although it looks like you already have the three +1 votes to  
> publish the
> 0.9.5 release, I'm hesitant with this publish since the current  
> OpenJPA
> implementation is using internal WebSphere methods.  I knew about the
> problem of not using the TransactionSynchronizationRegistry interface
> (OPENJPA-61), but I didn't realize the implications of using internal
> WebSphere methods to get around this issue.  Specifically, OpenJPA  
> is using
> the following method:
>
> com.ibm.ws.Transaction.TransactionManagerFactory.getTransactionManager

Is this a problem because you would like to see OpenJPA using more  
modern methods of getting at the TM, or because there are other  
serious consequences to calling this method? Note that Kodo has been  
using this method fine for years, and it looks like a number of other  
popular frameworks (Spring, Castor, and Hibernate, after some quick  
Googling on the method name) also use this method to get the WAS TM,  
so it doesn't seem uncommon.

> I would like to see this get resolved before we publish the 0.9.5  
> release.
> The OPENJPA-61 report has two aspects to it.  One is to use the new  
> JTA
> interface for Java EE 5 compliant environments.  That's one  
> problem.  But,
> the other, more immediate, problem is to remove the usage of internal
> WebSphere methods for existing WebSphere environments.  We will  
> attempt
> resolve this immediate problem first.  And, then worry about the
> TransactionSynchronizationRegistry.

If it is just a matter of using a more modern method to get the same  
TM functionality, then we can pretty quickly implement this by adding  
a new WASManagedRuntime that gets the TM in whatever way we want.  
However, if it doesn't work with older WAS versions, we should keep  
the old method around as well, since otherwise people won't have any  
way of integrating with this version.

Ideally, of course, everything would move towards the  
TransactionSynchronizationRegistry, but as I mentioned in OPENJPA-61,  
we currently rely internally on having a  
javax.transaction.Transaction instance for both managed and stand- 
along transactions. The quickest route to getting this to work would  
be to make some  
TransactionSynchronizationRegistryTransactionManagerFacade that  
returns a TransactionFacade implementation of  
javax.transaction.Transaction whose begin()/commit() methods are just  
no-ops or throw exceptions (since I don't think the Broker should  
ever be calling those methods when the "openjpa.TransactionMode" is  
set to "managed").

However, I haven't yet experimented with a container that supports  
the TransactionSynchronizationRegistry, so that implementation work  
would be best done by someone who has experience with one of those  
containers (hint :)

Anyway, in conclusion, I'm happy to see an update to the methods  
through which the transaction integration is performed provided we  
don't break backwards compatibility with older versions. I'd also  
rather not hold up 0.9.5 just for this ... we can always cut a new  
release pretty quickly once we get the updated integration working  
and tested, but in the near term, it'd be nice to get something out  
there beyond the nightly snapshots that people can start relying on.


> Thanks,
> Kevin
>
> On 10/18/06, Abe White <awhite@bea.com> wrote:
>>
>> +1
>> _____________________________________________________________________ 
>> __
>> Notice:  This email message, together with any attachments, may  
>> contain
>> information  of  BEA Systems,  Inc.,  its subsidiaries  and   
>> affiliated
>> entities,  that may be confidential,  proprietary,  copyrighted   
>> and/or
>> legally privileged, and is intended solely for the use of the  
>> individual
>> or entity named in this message. If you are not the intended  
>> recipient,
>> and have received this message in error, please immediately return  
>> this
>> by email and then delete it.
>>