BTM

error delisting resource error with Oracle 9

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 1.0
  • Fix Version/s: 1.0.1, 1.1
  • Labels:
    None
  • Environment:
    Oracle 9i, any version
  • Number of attachments :
    0

Description

I get this warning:

85297 [http-8080-Processor23] WARN bitronix.tm.internal.XAResourceManager - error delisting resource: an XAResourceHolderState with uniqueName=jdbc/dev1 XAResource=oracle.jdbc.driver.T4CXAResource@1d2bb9f (started) with XID a Bitronix XID [77326B2D6A617661352D7800000114D591018A0000002A : 77326B2D6A617661352D7800000114D5910A630000002F]
bitronix.tm.internal.BitronixSystemException: unknown XAResource oracle.jdbc.driver.T4CXAResource@1d2bb9f, it does not belong to a registered resource
at bitronix.tm.BitronixTransaction.delistResource(BitronixTransaction.java:84)
at bitronix.tm.internal.XAResourceManager.delistUnclosedResources(XAResourceManager.java:125)
at bitronix.tm.BitronixTransaction.commit(BitronixTransaction.java:123)
at bitronix.tm.BitronixTransactionManager.commit(BitronixTransactionManager.java:92)
...

then later on this error:

85360 [http-8080-Processor23] ERROR bitronix.tm.twopc.Rollbacker - cannot rollback resource an XAResourceHolderState with uniqueName=jdbc/dev1 XAResource=oracle.jdbc.driver.T4CXAResource@1d2bb9f (started) with XID a Bitronix XID [77326B2D6A617661352D7800000114D591018A0000002A : 77326B2D6A617661352D7800000114D5910A630000002F], error=XAER_RMFAIL, retrying in 10s
oracle.jdbc.xa.OracleXAException
at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1045)
at oracle.jdbc.xa.client.OracleXAResource.rollback(OracleXAResource.java:869)
at bitronix.tm.twopc.Rollbacker.rollbackResource(Rollbacker.java:110)
at bitronix.tm.twopc.Rollbacker.access$000(Rollbacker.java:23)
at bitronix.tm.twopc.Rollbacker$RollbackJob.run(Rollbacker.java:201)
at bitronix.tm.twopc.executor.SyncExecutor.submit(SyncExecutor.java:12)
at bitronix.tm.twopc.Rollbacker.rollback(Rollbacker.java:53)
at bitronix.tm.BitronixTransaction.lastChanceRollback(BitronixTransaction.java:265)
at bitronix.tm.BitronixTransaction.commit(BitronixTransaction.java:144)
at bitronix.tm.BitronixTransactionManager.commit(BitronixTransactionManager.java:92)
...

see http://www.nabble.com/ConnectionPool-Features-tf4361021.html for more details.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ludovic Orban added a comment -

This only happens if deferConnectionRelease is true.

There are actually two bugs behind this issue.

The first bug lies in JdbcPooledConnection.getConnection(). When the pool has been configured to test the connection all calls to getConnection() will result in the test query being executed even when the connection has been recycled. This should not be the case as the connection is supposedly fine if it is in use (prerequesite to recycling).

The second bug is in JdbcPooledConnection.testConnection(). After the connection is tested, a local rollback is executed. This is wrong, the test query should be read-only in itself so its work should be part of the current transaction.

If you mix both bugs in a case where a connection is being recycled then:

  • you get a recycled connection (-> already enlisted in the current transaction)
  • you test it (bug 1: not needed)
  • the test tries to call a local TX rollback (bug 2: tries to perform local rollback while in global TX context)
  • rollback throws a SQLException -> the connection is declared broken
  • the connection is closed and dropped
  • when the transaction reaches 2PC and the TM tries to delist the connection it is not part of the pool anymore -> no delistment -> 2PC fails
Show
Ludovic Orban added a comment - This only happens if deferConnectionRelease is true. There are actually two bugs behind this issue. The first bug lies in JdbcPooledConnection.getConnection(). When the pool has been configured to test the connection all calls to getConnection() will result in the test query being executed even when the connection has been recycled. This should not be the case as the connection is supposedly fine if it is in use (prerequesite to recycling). The second bug is in JdbcPooledConnection.testConnection(). After the connection is tested, a local rollback is executed. This is wrong, the test query should be read-only in itself so its work should be part of the current transaction. If you mix both bugs in a case where a connection is being recycled then: you get a recycled connection (-> already enlisted in the current transaction) you test it (bug 1: not needed) the test tries to call a local TX rollback (bug 2: tries to perform local rollback while in global TX context) rollback throws a SQLException -> the connection is declared broken the connection is closed and dropped when the transaction reaches 2PC and the TM tries to delist the connection it is not part of the pool anymore -> no delistment -> 2PC fails
Hide
Permalink
Ludovic Orban added a comment -

This will be fixed in the 1.1 release. Meanwhile, an intermediate 1.0.1 version will be released as this issue is pretty serious.

Show
Ludovic Orban added a comment - This will be fixed in the 1.1 release. Meanwhile, an intermediate 1.0.1 version will be released as this issue is pretty serious.
Hide
Permalink
Ludovic Orban added a comment -

Issue solved. Fix has been integrated in head + in 1.0 branch -> version 1.0.1 released.

Show
Ludovic Orban added a comment - Issue solved. Fix has been integrated in head + in 1.0 branch -> version 1.0.1 released.
Hide
Permalink
Amin Abbaspour added a comment -

The same error message appears on Oracle 10g when using wrong JDBC driver (e.g. using 10gR1 driver for 10gR2).

Show
Amin Abbaspour added a comment - The same error message appears on Oracle 10g when using wrong JDBC driver (e.g. using 10gR1 driver for 10gR2).

People

  • Assignee:
    Ludovic Orban
    Reporter:
    Ludovic Orban
Vote (0)
Watch (0)

Dates

  • Due:
    Created:
    Updated:
    Resolved: