-
Bug
-
Resolution: Done
-
Major
-
None
-
1.2.7.Final
-
None
PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception.
This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool.
The scenario is as follows:
- A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper.
- 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction.
- The connection is returned to the pool, cleanup() method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i.
- The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened.
- 2nd app receives the connection and calls setTransactionIsolation(), which throws an exception because the transaction is open.
Possible solution could be that the cleanup() method propagates the autocommit=true to the wrapped jdbc connection immediately.
- is cloned by
-
WFLY-8032 CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
- Closed
- is incorporated by
-
JBEAP-8789 (7.0.z) JBJCA-1338 - CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
- Closed
- is related to
-
JBJCA-1431 Reset autocommit during cleanup
- Resolved
-
JBEAP-9730 Incorrect outcome when CMR fails at commit phase
- Reopened