[DERBY-3319] Logical connections do not check if a transaction is active on close

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 10.3.2.1, 10.4.1.3, 10.5.1.1
• Fix Version/s: 10.5.1.1
• Component/s: JDBC, Network Client
• Environment: Embedded driver and client driver.
• Issue & fix info: Release Note Needed
• Assignee: Knut Anders Hatlen
• Reporter: Kristian Waagan
• Created: 15/Jan/08 14:44
• Updated: 14/Jul/09 17:52
• Resolved: 27/Oct/08 15:23

Description

If you call close on a logical connection, for instance as obtained through a PooledConnection, it does not check if there is an active transaction.
The close of the logical connection is allowed, and even the close of the parent PooledConnection is allowed in the client driver. This can/will cause resources to be left on the server, and later operations might fail (typically with lock timeouts because the "closed" transaction is still holding locks).
I do not know if gc will solve this eventually, but I would say the current behavior of the client driver is wrong in any case.
There is difference in the behavior between the embedded and the client driver, and there also seems to be a bug in the embedded driver.

The analysis above is a bit sketchy, so it might be required to look into the issue a bit more...
I will attach a repro (JDBC usage should be verified as well, is it legal / as intended?)

Issue Links

• is related to: DERBY-1191 Some SQLExceptions, for example those generated from BrokeredStatements, do not print to derby.log even when derby.stream.error.logSeverityLevel=0
• is related to: DERBY-4225 EmbeddedConnectionPoolDataSource40 never calls the ConnectionEventListener calbacks
• relates to: DERBY-4053 Network Server's failure to rollback local transactions on shutdown can cause hang on startup with message java.net.BindException: Address already in use: NET_Bind in derby.log