OpenSubsystems Java Business Components / Bugs / #282 WebSphere incorrectly manages autocommit state of connection

Logged In: YES
user_id=166079

This is response from IBM. They acknowledged it is most
likely defect in WebSphere code. Here is complete transcript
from the conversation:

Product: IBM WebSphere Application Server, Version 6
Customer's environment:
Amount of memory: 1024
Size of hard disk: 30gb
On a network? : yes

Description:
Recreatable? : yes
How often does the failure occur? : constantly

Problem description:

I am using websphere as 6.0.2.9 to evaluate it with our
project OpenSubsystems (www.opensubsystems.org). When we use
it with jTDS driver 1.2 to access MS SQLServer 2005, our
automated testcases constantly fail. These are consistently
passing on all other supported application servers
(WebLogic, JBoss, Jonas, ...). The issue is that WebSphere
incorrectly passes the autocommit state requested from
application to the underlying JDBC driver which causes the
JDBC driver to fail.

I have documented all the details and attached log files
from our application, jTDS driver and WebSphere at the
following URL
http://sourceforge.net/tracker/index.php?func=detail&aid=1487670&group_id=111437&atid=659213
------------------------Customer Tue May 16
15:46:29 GMT 2006

This problem may be related to problem #19693 I have
submitted earlier.
------------------------Customer Tue May 16
15:52:48 GMT 2006
I looked over the logs you posted at sourceforge for both
19692 and 19693.

I have some general topics to discuss for both of these
problem reports. I will post the generality here for
both 19692 and 19693. Some of this generality is restating
what you have told me to make sure I understand
your environment.

You are an open source developer who develops the jTDS JDBC
driver. You are testing it on WebSphere Application server
and have hit a failure in one of your test programs. You
are testing with WebSPhere 6.0.2.9, which happens to be the
latest service level available. The database is Microsoft
SQL Server.

You are also running the same test program using the same
database, but using the MQ SQL driver instead of the
jTDS driver. You run the MS driver in order to get a
reading on consistent operation, especially when you have a
test driver failure.

Correct so far?

Here is our support caveat:
We offer free limited support for WebSphere software trials.
The limitations are:
We offer help with installation. And we offer general
configuration help as well as help running the sample programs.
We do not offer help with debugging custom programs.
We do not offer defect support beyond pointing you to the
latest service, which you already have.

Since you are testing with a JDBC driver that is not in our
support list, we have no idea if our product
is supposed to work with that driver. We have never tested
that driver and do not claim it is supposed
to work.

However, lets proceed with the assumption that there may be
a easy fix, namely
that we may be alble to solve your problem with some changes
in configuration.
Let's see how far we get.

I notice you are using the generic datastore helper:
DSRA0174W: Warning: GenericDataStoreHelper is being used.

This is usually not a good choice for most databases,
especially MS SQL server.
What happens when you change the data source definition to use

com.ibm.websphere.rsadapter.WSConnectJDBCDataStoreHelper ??

If not that one, how about this one:
com.ibm.websphere.rsadapter.ConnectJDBCDataStoreHelper

If switching the datastore helper doesn't solve anything, I
need to take a closer look at your configuration.
Please run the collector tool according to the instructions
in this article:
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/ttrb_runct.html

Then upload the resultant JAR file via the problem
submission page upload link.

I also need to know the MS SQL Server level. The log
indicates 09.00.1399
Can you put this in Microsoft marketing lingo? Is this SQL
Server 2000?

Rudy
____________ IBM Response Tue May 16 19:20:18 GMT 2006

Hello Rudy,

I am not developing jTDS driver. We are developing framework
called OpenSubsystems. We just happen to use jTDS driver
because it is open source, it is supposed to be the fastest
available driver and it provides us consistent behavior
across all evironments.

The database we are using is MS SQL Server 2005 I believe SP1.

We are running our compatibility tests using our default
jTDS driver. I hav ealso tried to run them using the
embedded connectJDBC driver.

I understand your support restriction and I appreciate your
help. I have contacted you since I believe my simple test
case uncovered a potential defect within WebSPhere you might
be interested in knowing of and potentially fixing since it
may impact other customers as well. This should help you to
improve your application especially since it should be
easily reproducible since all the components (OpenSubsystems
Open Core and jTDS driver) your development team would need
to reproduce are open source and readily available.

When I tried to uue the helper class
com.ibm.websphere.rsadapter.WSConnectJDBCDataStoreHelper
and I tested the connection from within the admin console I
have received following exception

Test connection failed for data source OSSDS on server
server1 at node ws_server with the following exception:
javax.management.RuntimeMBeanException: null nested runtime
exception is java.lang.ClassCastException:
net.sourceforge.jtds.jdbcx.proxy.ConnectionProxy. View JVM
logs for further details.

and the log contains following exception
[5/17/06 12:39:09:320 CDT] 00000020 SystemErr R
java.lang.ClassCastException:
net.sourceforge.jtds.jdbcx.proxy.ConnectionProxy
at
com.ibm.websphere.rsadapter.WSConnectJDBCDataStoreHelper.doConnectionSetup(WSConnectJDBCDataStoreHelper.java:100)
at
com.ibm.ws.rsadapter.DSConfigurationHelper.testConnectionForGUI(DSConfigurationHelper.java:2196)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...

which seems to tell me that I cannot use the helper with
this database connection.

------------------------Customer Wed May 17
17:44:43 GMT 2006

With data helper
com.ibm.websphere.rsadapter.ConnectJDBCDataStoreHelper the
test connection suceeds, but when I try to run my test as
described above I get following error

Caused by: java.sql.SQLException: commit() should not be
called while in auto-commit mode.DSRA0010E: SQL State =
25000, Error Code = 0
at
net.sourceforge.jtds.jdbc.ConnectionJDBC2.commit(ConnectionJDBC2.java:1878)
at
net.sourceforge.jtds.jdbcx.proxy.ConnectionProxy.commit(ConnectionProxy.java:87)
at
com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.processLocalTransactionCommittedEvent(WSRdbManagedConnectionImpl.java:1743)
at
com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.commit(WSJdbcConnection.java:815)
at
org.opensubsystems.core.persist.db.DatabaseTransactionFactoryImpl.commitTransaction(DatabaseTransactionFactoryImpl.java:184)
at
org.opensubsystems.core.persist.db.DatabaseImpl.start(DatabaseImpl.java:475)
... 23 more
I will revert my configuration to the default settings and
sent you the file from the collector.
------------------------Customer Wed May 17
17:45:16 GMT 2006

------------------------Customer file uploaded
(XXXXXXXXXX-XXXXXXXXXXNode01Cell-ws_server-default-WASenv.jar)
------------------------Customer Wed May 17
18:07:05 GMT 2006
Very interesting that changing the helper causes the jtds
driver to behave like the IBM provided driver which you
describe in 19693. This does confirm that these two
seemingly different issues are essentially the same issue.

I'll proceed to analyze the collector you sent for 19693.
Once I complete that analysis, I'll have a plan for the next
step.

____________ IBM Response Wed May 17 18:09:10 GMT 2006
I conclude that this behavior is cause by using the wrong
datastore helper class. When you use the correct class, you
then get the behavior described in 19693, which I have
concluded is a defect.

Rudy

WebSphere incorrectly manages autocommit state of connection

Group

Searches

Help

#282 WebSphere incorrectly manages autocommit state of connection

Discussion