Weblogic JTA timeout and PreparedStatement cache problem (Closed Statement)

Question

Hello,
I am facing up a problem using a Weblogic connection pool with a PreparedStatement.
Here is the environement :
- Weblogic application server 10.3
- JDBC connection pool with Oracle Thin driver (from server library) - all parameters by default i.e. StatementCache size = 10
- JTA transaction timeout = 30s
The problem is : if a prepared statement ends because of a JTA timeout, I receive the following stack exception/ stack trace
java.sql.SQLException: The transaction is no longer active - status: 'Rolling Back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 33 seconds
BEA1-000D8AE7230EFAA3EDC9]'. No further JDBC access is allowed within this transaction.
at weblogic.jdbc.wrapper.JTSConnection.checkIfRolledBack(JTSConnection.java:178)
at weblogic.jdbc.wrapper.JTSConnection.checkConnection(JTSConnection.java:188)
at weblogic.jdbc.wrapper.Connection.preInvocationHandler(Connection.java:92)
at weblogic.jdbc.wrapper.Connection.clearCachedStatement(Connection.java:814)
at weblogic.jdbc.wrapper.PreparedStatement.clearCachedStatement(PreparedStatement.java:1357)
and then, if we try to re-execute immediately the same operation (*same statement* but new request, new thread, new JTA transaction ...) we receive without delay the following exception :
java.sql.SQLException: Closed Statement
at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:70)
at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:403)
It seems like a bug in the caching mechanism of Weblogic, the 1st stack trace shows method from the statement cache implementation, I presume weblogic is trying the clear the statement from the cache after the iniitial TimedOutException (SQLException), but as the JDBC connection is unusable at this point, the clearing fails and the statement remains in the cache but is physically closed by JDBC.
1st question, why weblogic does need to call JTSConnection.checkConnection() for clearing a statement from its internal cache, it is a pure java memory operation isnt'it ?
2nd question : How to solve the problem without setting the StatementCache size to 0 (I tried, it solves the problem)? I don't want to disable completely the Weblogic statement caching, I have a small PreparedStatement called very frequently.
Thanks for any help

Answer 1

The main issue is that the transactional context that is supposed to underlay the JDBC code being executed,
has gone away. Indeed, any DBMS changes that may have been made by your code so far, have been rolled
back and are gone. Your code should not be trying to continue JDBC as normal, and WebLogic is trying to stop
you. The control flow should go back up to the location where the transaction was initiated, so as to restart from
the beginning if that is what is desired, including getting a new JDBC connection and remaking all the statements
etc.
HTH,
Joe
Edited by: Joe Weinstein on Dec 3, 2010 9:12 AM