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 <[EMAIL PROTECTED]> 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.
