Missing usage of TransactionSynchronizationRegistry

• Key: OPENJPA-61
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Kevin Sutter
• Reporter: Kevin Sutter
• Component/s: jdbc
• Fix Version/s: 1.0.0

Description

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 <[e-mail]> 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/AutomaticManagedRuntime.java

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.
========================================================================================

Comments

[Kevin Sutter]

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 are:

        "com.ibm.ejs.jts.jta.JTSXA.getTransactionManager"
        "com.ibm.ejs.jts.jta.TransactionManagerFactory.getTransactionManager"
        "com.ibm.ws.Transaction.TransactionManagerFactory.getTransactionManager"

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.

Kevin

[Kevin Sutter]

Question: From a pure JPA perspective, you would need WebSphere v6.1 Application Server in order to use OpenJPA within a WebSphere container (at a minimum). This is due to the requirement of Java SE 5, which was first available in WAS v6.1. So, if the use of the proper ExtendedJTATransaction interface was limited to JPA, then we could remove the other three internal API references. But, since this OpenJPA kernel is also used by Kodo's JDO support, what levels of the WebSphere runtime need to be supported? The ExtendedJTATransaction interface was introduced in WAS v5.0.2. Since WAS v4.x is out of service, do we need to leave the three internal API references in the code base? Or, can these be removed once we get the ExtendedJTATransaction processing committed?

[Patrick Linskey]

I'd say that we (OpenJPA) should not worry about the older versions -- we (BEA) will just need to add the appropriate logic in Kodo to handle the older versions of WebSphere.

[Marc Prud'hommeaux]

The attached patch might work. It contains a new RegistryManagedRuntime class that just uses a TransactionManager facade around a TransactionSynchronizationRegistry. This will allow us to use the standard TransactionSynchronizationRegistry interface without breaking the ManagedRuntime contracts. The only shortcoming is that direct control over the Transaction will fail (since TransactionSynchronizationRegistry doesn't provide direct access to the current Transaction).

Note also that this patch will require us to update our JTA dependency from geronimo-jta_1.0.1B_spec to geronimo-jta_1.1_spec. I don't envision that being a problem, since it should be backwards-compatible.

I will need someone who has access to a container that supports the TransactionSynchronizationRegistry interface to test this out before we can commit it.

[Michael Dick]

Marc, I started testing this with the WebSphere EJB3 feature pack. So far I haven't found any bugs, but I've really only run a few simple tests. I'll add more comments to the JIRA when I've tested it more thoroughly.

[Marc Prud'hommeaux]

Note that you should make sure that you are really using the new RegistryManagedRuntime, since if any exceptions occur when loading that class, they will be silently consumed and it will fall back to using the old internal APIs for accessing the TransactionManager.

You should be able to force it to use the new class by specifying "openjpa.ManagedRuntime" to be "org.apache.openjpa.ee.RegistryManagedRuntime".

[Michael Dick]

The patch looks good on our end, running with the Transacton Synchronization Registry in WebSphere. If other vendors would like to test it out as well that's fine with me, but you have my +1 to integrate..

[Kevin Sutter]

Committed a slightly-modified version of Marc's patch. All of our junit tests pass (of course) and it seems to work well in the WebSphere environment. We need to work through any wrinkles with this TransactionSynchronizationRegistry, so we might as well go ahead with the integration. Thanks, Marc, for the patch!

[Patrick Linskey]

I don't think that we want this to necessarily be the default ManagedRuntime implementation, since the TSR does not provide any support for executing work in a separate transaction. This behavior is required for sequence maintenance in some scenarios.

Maybe we should change our ManagedRuntime interface to get rid of the begin() / commit() etc. APIs, and add a new interface for executing a Runnable in a different transaction. This would allow us to use the TSR ManagedRuntime for general use, and just plug in different ways of performing out-of-transaction work.

Thoughts?

[Kevin Sutter]

Patrick, I agree with that idea. That was exactly along the lines of my thinking, but I needed to get the first step done first -- get the TSR available. Our "hack" for utilizing the WebSphere JTAExtendedTransaction interface wasn't cutting it and the TSR implementation that Marc provided got us around a couple of the problems. So, I wanted to get a portion of the fix integrated. Since the original problem as documented was resolved, I will create a new Issue to cover this additional "out of transaction" work request. Sound okay?