JDBCConfigurationImpl does not support JNDI lookup for non-jta-data-source.

• Key: OPENJPA-144
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: Brad L Vandermoon
• Component/s: jdbc
• Fix Version/s: 0.9.7

Description

A non-jta-data-source is required for DB2 sequences; however, org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl does not support a JNDI lookup for this data source from the openjpa.ConnectionFactory2Name property as documented (refer to section 5.12 and 4.2.1 of the OpenJPA manual).

It seems like the same implementation for the jta-data-source should be implemented for the non-jta-data-source. i.e.

// ADD createConnectionFactory2()
private DecoratingDataSource createConnectionFactory2() {
        DataSource ds = (DataSource) connectionFactory2.get();
        if (ds != null)
            return setupConnectionFactory(ds, true);

        ds = (DataSource) super.getConnectionFactory2(); // JNDI lookup
        if (ds == null)
            ds = DataSourceFactory.newDataSource(this, true);

        return setupConnectionFactory(ds, true);
    }

// MODIFY this method
public Object getConnectionFactory2() {
        // override to configure data source
        if (dataSource2 == null) {
            DecoratingDataSource ds = createConnectionFactory2();
            dataSource2 = DataSourceFactory.installDBDictionary
                (getDBDictionaryInstance(), ds, this, true);
        }
        return dataSource2;
    }

Comments

[Patrick Linskey]

Are you also specifying a jta-data-source, or only a non-jta-data-source? If specifying both, what error do you get when you don't specify a non-jta-data-source at all? I believe that there could be a problem, but I did some work a while back that makes it unnecessary to specify a non-jta-data-source if you're specifying a jta-data-source. That code works on WebLogic, but that's the only environment that I've tested it in.

[Brad L Vandermoon]

The above solution is offered as an analysis level solution only. Testing is in process.

[Brad L Vandermoon]

When we specify only a jta-data-source, we get: "<4|false|0.9.7-incubating-SNAPSHOT> org.apache.openjpa.util.InvalidStateException: Unable to execute suspend on a WebSphere managed transaction. WebSphere does not support direct manipulation of managed transactions."

When we try to use JNDI to specify the non-jta-data-source, we get the same error. JDBCConfigurationImpl doesn't appear to use this information to populate datasource2.

When we pass the properties to have OpenJPA create the connection it works fine. Here's the properties we pass:

       <entry key="openjpa.Connection2DriverName" value="com.ibm.db2.jcc.DB2Driver"/>
        <entry key="openjpa.Connection2UserName" value="Test"/>
        <entry key="openjpa.Connection2Password" value="password"/>
        <entry key="openjpa.Connection2URL" value="jdbc:db2://localhost:3700/RQSTSET"/>
        <entry key="openjpa.jdbc.Schema" value="PROPCAS"/>

In this later case, JDBCConfigurationImpl creates a SimpleDriverDataSource for the datasource2 and uses it to do the sequence.

[Patrick Linskey]

Interesting. Can you post the full stack trace both without specifying a non-jta-data-source and with a non-jta-data-source specified?

[Brad L Vandermoon]

Requested stack traces provided above. I also verified that JDBCConfigurationImpl.connectionFactory2Name contained my non-jta-data-source reference (i.e. "java:comp/env/jdbc/RequestSetNoTran") when producing Both-JTAandNonJTASpecified.txt.

[Patrick Linskey]

It looks like there are two issues here. First, we seem to be incorrectly attempting to suspend the transaction when a non-jta data source is specified. Second, our WAS integration does not allow suspending of the JTA transaction. I will create a new issue for this second problem.

[Brad L Vandermoon]

Great. Is there something I can do?

[Patrick Linskey]

If you could create and attach a patch akin to what you described in the original notes, that'd be great. One modification: instead of adding a new createConnectionFactory2() method, it'd be great if you could just modify the (private) createConnectionFactory() method that exists already, maybe to take as an argument a boolean indicating which connection factory to use.

[Patrick Linskey]

It turns out I had a few free minutes. Attached is a wholly-untested patch to JDBCConfigurationImpl.java that might work. Can you test this out and let me know if it works?

If you don't have access to the OpenJPA sources, I can build a jar with the patched class in it for testing also.

[Brad L Vandermoon]

I will test today.

[Brad L Vandermoon]

I thought I could get this from the svn repository, but it does not appear as though the java file has been checked in. If you'd attach the java file, I can test.

Bottom line I only have access to the subversion web interface.

[Patrick Linskey]

I've attached a jar file containing the compiled class. Put this jar ahead of OpenJPA in your classpath.

FTR, the source for the file in question is at https://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/conf/JDBCConfigurationImpl.java

[Brad L Vandermoon]

The error has changed a bit. New stack trace is in PostPatch-144. Debugging indicates that JDCConfigurationImpl.datasource2 contains a managed datasource.

Oops, I made a mistake in the createConnectionFactory() logic. This one looks better.

[Brad L Vandermoon]

I am getting a different error this time, but before I pass on the stack trace information, perhaps you can tell me what properties you'd expect to see set i.e. non-jta-data-source, openjpa.Connection2DriverName, openjpa.ConnectionFactory2Name, etc.....

[Patrick Linskey]

For openjpa-144-patch-2.jar, I would expect you to need to set jta-data-source and non-jta-data-source appropriately. The second patch should correctly pick up the non-jta-data-source and use it for sequence purposes.

[Brad L Vandermoon]

Getting a different exception now. It is contained in attached "PostPatch-144fix2.txt". It appears as though all JNDI lookups in WebSphere return a managed connection as JDBCConfigurationImpl.datasource2 contains an instance of com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.

Just to recap. Without the patches, I have been able to get sequences two work by two different methods:

Approach 1: specify connection properties so OpenJPA can build a SimpleDriverDataSource. Properties are as follows:

        <entry key="openjpa.Connection2DriverName" value="com.ibm.db2.jcc.DB2Driver"/>
        <entry key="openjpa.Connection2UserName" value="Test"/>
        <entry key="openjpa.Connection2Password" value="xxxxxxxx"/>
        <entry key="openjpa.Connection2URL" value="jdbc:db2://localhost:3700/RQSTSET"/>
        <entry key="openjpa.jdbc.Schema" value="PROPCAS"/>

       Under this approach, SimpleDriverDataSource is contained in JDBCConfigurationImpl.datasource2.

Approach 2: pass the webspeher transaction manager to OpenJPA per the below property:

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

[Patrick Linskey]

I'm guessing that Approach 2 works with just a single jta-data-source listed, right?

Also, your description implies that with the most recent code, OpenJPA is looking up the non-jta-data-source, but WAS is still returning a data source with limitations. Is that correct? Based on this assumption, I will close this issue and create a new one re: our defaults and corresponding WAS limitations.

[Brad L Vandermoon]

Approach 2 will actually work when specifying only the jta-data-source or specifying both the jta-data-source and the non-jta-data-source.

As far as your second question: WAS is retuning a managed connection for the second data source.