openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <>
Subject [jira] Commented: (OPENJPA-61) Missing usage of TransactionSynchronizationRegistry
Date Fri, 20 Oct 2006 16:09:35 GMT
    [ ] 
Kevin Sutter commented on OPENJPA-61:

It's turning out that we have two problems to resolve via this defect.  The first (more immediate)
problem is to remove the usage of the internal WebSphere API usage.  Currently, OpenJPA is
using one of three API's to get access to the WebSphere TransactionManager.  These API's were
never meant to be used by applications or other persistence mechanisms.  The API's in question


Instead, the preferred (public, documented) method of interfacing with the WebSphere TransactionManager
is via the
ExtendedJTATransaction interface.  This provides similar access to TM-like functions without
opening direct access to the TM, which could possibly cause integrity issues.  This will involve
looking up the java:/comp/websphere/ExtendedJTATransaction object, and then using this object
to register for synchronization (which also uses a websphere-specific interface, to protect
the innocent).

That's the first step.  We need to do this first so that we can get WebSphere's buy-in of
the OpenJPA project.

The follow-on issue is to introduce the usage of the Java EE 5 feature for the TransactionSynchronizationRegistry.
 This will standardize the persistence provider's access to TM's across all Java EE 5 application
servers.  We will leave the other mechanisms in place for non-Java EE 5 compliant application
servers, but the TransactionSynchronizationRegistry will be the first option to try.  Once
we get the first item complete (using the WebSphere interfaces), this item should follow shortly.

Please comment with any questions or concerns with this approach.  Thanks.


> Missing usage of TransactionSynchronizationRegistry
> ---------------------------------------------------
>                 Key: OPENJPA-61
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jdbc
>            Reporter: Kevin Sutter
> A discussion on the dev mailing list indicates that OpenJPA currently does not utilize
the TransactionSynchronizationRegistry.  Although OpenJPA does provide other means of finding
and accessing the various TransactionManagers, we should update OpenJPA to use the standard
interfaces.  Following are the two notes on this subject...
> ========================================================================================
> o  David Jencks 	<> to open-jpa-dev 	 More options	  Sep
27 (19 hours ago)
> I'm trying to get openjpa running in geronimo and wonder how openjpa
> locates the TransactionSynchronizationRegistry.  Grep'ing for
> TransactionSynchronizationRegistry I don't see it used anywhere in
> the code base.  What am I missing?
> thanks
> david jencks
> ========================================================================================
> o  Marc Prud'hommeaux 	to open-jpa-dev	 More options	  Sep 27 (19 hours ago)
> David-
> We don't use TransactionSynchronizationRegistry (not yet, at least).
> Instead, we manually locate the TransactionManager via appserver-
> specific heuristics defined in openjpa-kernel/src/main/java/org/
> apache/openjpa/ee/
> If the Geronimo TransactionManager is accessible from JNDI or some
> method invocation, you can just add it into AutomaticManagedRuntime
> as a default (you can test it out by specifying the
> "openjpa.ManagedRuntime" property to "jndi
> (TransactionManagerName=java:/GeronimoJNDINameForTransactionManager)".
> We may add support for integration via
> TransactionSynchronizationRegistry in the future, but the fact that
> it doesn't provide support for accessing the current Transaction
> would mean that we would need to rework some OpenJPA internals.
> ========================================================================================

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message