non-jta-data-source must be specified in WebSphere environments

• Key: OPENJPA-149
• Type: Improvement
• Status: Resolved
• Resolution: Fixed
• Priority: Blocker
• Assignee: Michael Dick
• Reporter: Patrick Linskey
• Component/s: kernel
• Affects Version/s: 0.9.6
• Fix Version/s: 1.2.0

Description

The suspend(), resume(), begin(), and commit() methods in org.apache.openjpa.ee.WASManagedRuntime$WASTransaction all throw exceptions. This prevents the logic in org.apache.openjpa.jdbc.kernel.AbstractJDBCSeq from executing. See OPENJPA-144 for relevant stack traces. In particular, look at the Only-JTASpecified.txt trace.

Comments

[Patrick Linskey]

This is primarily a usability issue.

[Patrick Linskey]

According to OPENJPA-144, it would seem that this can be resolved with the following properties entry:

        <entry key="openjpa.ManagedRuntime" value="invocation(TransactionManagerMethod=com.ibm.ws.Transaction.TransactionManagerFactory.getTransactionManager)"/>

[Kevin Sutter]

The referenced method (com.ibm.ws.Transaction.TransactionManagerFactory.getTransactionManager) is an internal WebSphere SPI and should not be recommended as a resolution for the problem.

[Brad L Vandermoon]

Is there a recommended solution on how to use DB2 SEQUENCES in websphere?

[Kevin Sutter]

Brad,
For now, go ahead and use the workaround as documented by Patrick's comment. This is not the preferred method (from a WebSphere perspective), but if it helps with your immediate usage of db2 sequences, then go for it. The use of the internal WebSphere TransactionManager interfaces should be considered a temporary workaround. I am waiting for a new transaction API from WebSphere development before I can formally resolve this Issue. According to my sources, this should be available soon. Thanks for your patience.

Kevin

[Kevin Sutter]

I am assigning this Issue to version 0.9.7, although it really doesn't require a change in the OpenJPA code. This Issue is dependent on a change in the WebSphere code that should be in the Beta release for the EJB3/JPA Feature Pack. I will also assign this Issue to myself for tracking purposes.

[Craig Russell]

This issue is marked as "fix for 0.9.8". Is it still important? Is it ok to require the use of the non-transactional data source or use Patrick's workaround?

[Kevin Sutter]

Clarifying a couple of my earlier comments...

The use of non-jta-data-sources in WebSphere will allow the use of DB2 Sequences. This support does not require the ability to suspend the current transaction. But, it would still be nice to have the ability to access database sequences without requiring the use of non-jta-data-sources. This transaction suspension can be done via WebSphere's UOWSynchronizationRegistery API. We should use this JIRA Issue to track this additional "feature". In the mean time, WebSphere users should use the spec-compliant non-jta-data-source element.

Through discussions with Patrick, he has indicated a desire to make this support more general so that it could apply to other environments more easily. He has opened OPENJPA-159 for this purpose. Thus, these two Issues (OPENJPA-159 and OPENJPA-149) are very much related.

Just wanted to clarify my earlier comments and what the differences are between 149 and 155.

Kevin

[Kevin Sutter]

Mike can have this one as well... :-)

[Kevin Sutter]

It doesn't look like this Issue will be doable before the 1.0.0 cutoff. Since the spec-compliant means is to use the non-jta-data-source element, WebSphere has a solution that works. So, this is not a "stop ship" requirement for the 1.0.0 release.

[Michael Dick]

Added new WASRegistryManagedRuntime which extends RegistryManagedRuntime. WASRegistryManagedRuntime implements the doNonTransactionalWork method and takes advantage of the WebSphere proprietary UOW API.

I also committed binary versions of the WebSphere UOW API in order to resolve compile time dependencies. These binary files are not included in our jars and are not redistributed. The license agreement for use of these binaries is included in openjpa-kernel/src/resources/com/ibm/license.txt. This may need to be moved to a more correct location in the future.