|
Should we then reconsider what happens to the holdability of the connection handle(got by calling a getConnection() method on a XAConnection OUTSIDE the global transaction) when it becomes part of a global transaction?
Following example code shows that Derby currently (silently) switches the the holdability of the connection handle from HOLD_CURSORS_OVER_COMMIT to CLOSE_CURSORS_AT_COMMIT when it becomes part of the global transaction. EmbeddedXADataSource dscsx = new EmbeddedXADataSource(); dscsx.setDatabaseName("wombat"); XAConnection xac = dscsx.getXAConnection("fred", "wilma"); XAResource xr = xac.getXAResource(); Xid xid = getXid(27, (byte) 21, (byte) 01); Connection conn1 = xac.getConnection(); System.out.println("By default, autocommit is " + conn1.getAutoCommit() + " for a connection"); System.out.println("Default holdability for a connection is HOLD_CURSORS_OVER_COMMIT"); System.out.println("CONNECTION(not in xa transaction yet) HOLDABILITY " + (conn1.getHoldability() == ResultSet.HOLD_CURSORS_OVER_COMMIT)); xr.start(xid, XAResource.TMNOFLAGS); System.out.println("Notice that autocommit now is " + conn1.getAutoCommit() + " for connection because it is part of the global transaction"); System.out.println("Notice that connection's holdability at this point is CLOSE_CURSORS_AT_COMMIT because it is part of the global transaction"); System.out.println("CONNECTION(in xa transaction) HOLDABILITY " + (conn1.getHoldability() == ResultSet.HOLD_CURSORS_OVER_COMMIT)); Output of this code snippet when run under Derby is as follows. START XA HOLDABILITY TEST By default, autocommit is true for a connection Default holdability for a connection is HOLD_CURSORS_OVER_COMMIT CONNECTION(not in xa transaction yet) HOLDABILITY true Notice that autocommit now is false for connection because it is part of the global transaction Notice that connection's holdability at this point is CLOSE_CURSORS_AT_COMMIT because it is part of the global transaction CONNECTION(in xa transaction) HOLDABILITY false thanks, Mamta I think the point is being missed that Derby does not support holdability when in a global transaction, thus holdability should always be CLOSE_CURSORS_AT_COMMIT when in a global transaction, regardless of the state set by the connection in local mode. So I believe the bug summary is correct, and there is a bug.
I have a patch to fix Derby-8 (Connection object gets created with un-supported holdability on getting Connection object from XAConnection "inside" the global transaction) and Derby-366 (In jdk13, when a connection transitions from global transaction to local transaction, its default holdability of HOLD_CURSORS_OVER_COMMIT is not restored.) The patch is attached to both Derby-8 and Derby-366.
The fix for both these bugs was centered around fixing the holdability handling in BrokeredConnection.java This was because BrokeredConnection.java had no code for restoring the holdability of real connection object and no code for saving the current holdability state of real connection object. I put fix for both these issues in BrokeredConnection.java so that both jdk13 and jdk14+ environments will be handled correctly. Had to use reflection for this holdability work because Connection.setHoldability and Connection.getHoldability methods are not available through JDK13 apis. svn stat M java\engine\org\apache\derby\iapi\jdbc\BrokeredConnection.java M java\engine\org\apache\derby\iapi\jdbc\BrokeredConnection30.java M java\testing\org\apache\derbyTesting\functionTests\tests\store\xaOffline1.sql M java\testing\org\apache\derbyTesting\functionTests\tests\store\xab2354.sql M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\xaAnotherTest.sql M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\xaSimplePositive.sql M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\xaSimpleNegative.sql M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\checkDataSource30.java M java\testing\org\apache\derbyTesting\functionTests\master\xaOffline1.out M java\testing\org\apache\derbyTesting\functionTests\master\xaSimplePositive.out M java\testing\org\apache\derbyTesting\functionTests\master\xab2354.out M java\testing\org\apache\derbyTesting\functionTests\master\xaSimpleNegative.out M java\testing\org\apache\derbyTesting\functionTests\master\xaAnotherTest.out M java\testing\org\apache\derbyTesting\functionTests\master\checkDataSource30.out Kathey, may be you can try this fix with Network Server and see if it resolves any related issues you had there? I have run the test suite and this fix has not caused any failures. Have changed some of the existing XA tests so that they can rely on correct holdability status inside and outside global transaction. If no comments from anyone, can a commiter please commit this patch? Checked this in.
Transmitting file data ............... Committed revision 191755. The fix has been committed by Kathey
Need to put correct fix-in version
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Minor
Connection object gets created with un-supported holdability on getting Connection object from XAConnection "inside" the global transaction
Both the XAResource and the Connection handle got by calling a getConnection() method on a XAConnection are child entities of the XAConnection. So the XAResource and the Connection are in parallel if a hierarchy is imagined with a XAConnection as the head.
So the Connection handle got by calling a getConnection method on the XAResource is not bound to have the same holdability for cursors as that of the Transaction. It should have its own holdability state.
Moreover in a managed sscenario the XAConnection interface is not directly used, we just get a java.sql.Connection handle by calling the getConnection method on the DataSource. It is the DataSource configuration that determines what all happens behind the scene to return a Connection handle.
So in my opinion Derby is behaving properly.