Embedded returns wrong value for DatabaseMetaData.autoCommitFailureClosesAllResultSets()

• Key: DERBY-3422
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Knut Anders Hatlen
• Reporter: Knut Anders Hatlen
• Component/s: JDBC
• Affects Version/s: 10.4.1.3
• Fix Version/s: 10.3.3.0, 10.4.1.3

Description

DatabaseMetaData.autoCommitFailureClosesAllResultSets() returns false both on the client and on embedded. However, the embedded driver does in fact close all open result sets when an error occurs in auto-commit mode. There is a test case in jdbc4.TestDbMetaData to test this (testAutoCommitFailure), but it only uses ResultSet.isClosed() to check whether or not the result set is closed after the failure. Because of DERBY-3404, isClosed() returns false for the result sets that have been closed because of the failure, so the test doesn't reveal the bug. If the test is changed to invoke methods on the result set (e.g. next()) instead of calling isClosed(), we'll see that the result set is in fact closed and get an SQLException with SQL state XCL16.

Comments

[Knut Anders Hatlen]

Attaching a patch which updates the test so that it exposes the bug. Instead of calling isClosed(), it calls ResultSet.next() and checks whether an exception with SQL state XCL16 is thrown. With this change, the test fails on embedded and passes on the client.

[Knut Anders Hatlen]

Attached is a patch that changes the return value for EmbedDatabaseMetadata40.autoCommitFailureClosesAllResultSets() and updates TestDbMetaData.

When this patch is applied, autoCommitFailureClosesAllResultSets() returns different values on embedded and on the client, so if the approach is accepted and the patch is committed, we should also file an issue to track the difference between client and embedded.

[Knut Anders Hatlen]

Committed revision 629395.

[Knut Anders Hatlen]

DERBY-3436 is logged to track the difference between embedded and client.

[Mamta A. Satoor]

Merged revision 629395 from trunk into 10.3.2.2 codeline(630941). The reason for merge is that I would like to merge changes for DERBY-3304 (629926) into trunk but that revision depends on DERBY-3404 (629712) which depends on DERBY-3422 (629395)