You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Marc Prud'hommeaux <mp...@apache.org> on 2006/10/19 00:39:31 UTC
Re: TransactionManagerFactory and WAS (was: [VOTE] publish openjpa 0.9.5-incubating podling release)
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 <aw...@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.
>>
Re: TransactionManagerFactory and WAS (was: [VOTE] publish openjpa 0.9.5-incubating podling release)
Posted by Kevin Sutter <kw...@gmail.com>.
On 10/18/06, Craig L Russell <Cr...@sun.com> wrote:
>
> I think that there are a few issues being discussed here.
>
> 1. Best practice for OpenJPA when running with servers/containers
> implementing the TransactionSynchronizationRegistry is to use this
> interface to register for transaction events of interest. There is a
> well-known JNDI name for the instance that implements the interface
> when running in a standard Java EE 5 environment. So this should be
> done in preference to other proprietary mechanisms.
>
> But this interface is not guaranteed to be available if running in
> older servers. In particular, AFAIK, Websphere does not yet ship a
> product that implements this interface. So,
Agree. TransactionSynchronizationRegistry is the preferred method for Java
EE 5 environments.
2. For pre-TSR servers, what do we do? Best practice here is to use
> the proprietary mechanisms of the servers, but do so in a way that
> does not require the implementation to be dependent on the
> proprietary interfaces unless running in that environment.
Agree, as long as the interfaces being used are public and documented (as
your next bullet outlines).
3. I don't see an issue using proprietary (public, documented)
> interfaces as an alternative to TSR. This is a time-honored way to
> get what you need given what is available.
Agree again.
I've just looked at the implementation of *ManagedRuntime in the
> org.apache.openjpa.ee package and found best practice 2 to be
> implemented. Nice job, Marc (attribution in code).
Yes, the implementation provided is flexible enough for the various
application servers. The "problem" is with WebSphere's access to the
TransactionManager. For reasons that do not directly pertain to this
discussion, access to the WebSphere TM was not made available via public,
documented interfaces until WAS 5.1. Previous to this, the undocumented,
internal TransactionManagerFactory interfaces were used by several vendors.
Since these internal interfaces can change and have changed in the past, WAS
eventually provided the ExtendedJTATransaction interface.
Using TSR will require a non-trivial change to the classes in the
> package. In particular, there will need to be a definition of an
> interface that performs the required registrations without a real
> implementation of TransactionManager.
>
> I don't believe that this is a reason to hold up the release. I hope
> we will be supporting pre-Java EE 5 servers for several years to come.
Agree. That's why I voted neutral. I didn't want to hold up the release.
Just wanted to voice my concern with the use of these internal interfaces.
Mike and I are working on an update. Thanks.
Craig
>
> On Oct 18, 2006, at 3:39 PM, Marc Prud'hommeaux wrote:
>
> > 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.getTransactionManage
> >> r
> >
> > 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 <aw...@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.
> >>>
> >
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
>
Re: TransactionManagerFactory and WAS (was: [VOTE] publish openjpa
0.9.5-incubating podling release)
Posted by Craig L Russell <Cr...@Sun.COM>.
I think that there are a few issues being discussed here.
1. Best practice for OpenJPA when running with servers/containers
implementing the TransactionSynchronizationRegistry is to use this
interface to register for transaction events of interest. There is a
well-known JNDI name for the instance that implements the interface
when running in a standard Java EE 5 environment. So this should be
done in preference to other proprietary mechanisms.
But this interface is not guaranteed to be available if running in
older servers. In particular, AFAIK, Websphere does not yet ship a
product that implements this interface. So,
2. For pre-TSR servers, what do we do? Best practice here is to use
the proprietary mechanisms of the servers, but do so in a way that
does not require the implementation to be dependent on the
proprietary interfaces unless running in that environment.
3. I don't see an issue using proprietary (public, documented)
interfaces as an alternative to TSR. This is a time-honored way to
get what you need given what is available.
I've just looked at the implementation of *ManagedRuntime in the
org.apache.openjpa.ee package and found best practice 2 to be
implemented. Nice job, Marc (attribution in code).
Using TSR will require a non-trivial change to the classes in the
package. In particular, there will need to be a definition of an
interface that performs the required registrations without a real
implementation of TransactionManager.
I don't believe that this is a reason to hold up the release. I hope
we will be supporting pre-Java EE 5 servers for several years to come.
Craig
On Oct 18, 2006, at 3:39 PM, Marc Prud'hommeaux wrote:
> 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.getTransactionManage
>> r
>
> 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 <aw...@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.
>>>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!