OpenJPA
  1. OpenJPA
  2. OPENJPA-149

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

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 0.9.6
    • Fix Version/s: 1.2.0
    • Component/s: kernel
    • Labels:
      None
    • Environment:
      WebSphere

      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.

        Issue Links

          Activity

          Hide
          Michael Dick added a comment -

          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.

          Show
          Michael Dick added a comment - 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.
          Hide
          Kevin Sutter added a comment -

          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.

          Show
          Kevin Sutter added a comment - 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.
          Hide
          Kevin Sutter added a comment -

          Mike can have this one as well...

          Show
          Kevin Sutter added a comment - Mike can have this one as well...
          Hide
          Kevin Sutter added a comment -

          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

          Show
          Kevin Sutter added a comment - 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
          Hide
          Craig L Russell added a comment -

          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?

          Show
          Craig L Russell added a comment - 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?
          Hide
          Kevin Sutter added a comment -

          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.

          Show
          Kevin Sutter added a comment - 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.
          Hide
          Kevin Sutter added a comment -

          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

          Show
          Kevin Sutter added a comment - 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
          Hide
          Brad L Vandermoon added a comment -

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

          Show
          Brad L Vandermoon added a comment - Is there a recommended solution on how to use DB2 SEQUENCES in websphere?
          Hide
          Kevin Sutter added a comment -

          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.

          Show
          Kevin Sutter added a comment - 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.
          Hide
          Patrick Linskey added a comment -

          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)"/>

          Show
          Patrick Linskey added a comment - 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)"/>
          Hide
          Patrick Linskey added a comment -

          This is primarily a usability issue.

          Show
          Patrick Linskey added a comment - This is primarily a usability issue.

            People

            • Assignee:
              Michael Dick
              Reporter:
              Patrick Linskey
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development