Language result sets should not reuse current isolation level across executions

• Key: DERBY-2597
• Type: Sub-task
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Knut Anders Hatlen
• Reporter: Knut Anders Hatlen
• Component/s: SQL
• Affects Version/s: 10.3.1.4
• Fix Version/s: 10.3.1.4

Description

Some of the language result sets cache the current isolation level in their constructors. To allow reuse of the result sets, they should check the isolation level each time they are opened. Currently, this affects HashScanResultSet, TableScanResultSet, LastIndexKeyResultSet and UpdateResultSet (and their sub-classes).

Comments

[Knut Anders Hatlen]

The attached patch (derby-2597-1) solves the problem for HashScanResultSet, TableScanResultSet and LastIndexKeyResultSet (and their sub-classes) by refreshing the isolation level on each open. Since the code that found the correct isolation level and lock mode was almost identical in all those classes, I created a common base class for them (ScanResultSet) and removed the duplicated code.

With this patch, ResultSetsFromPreparedStatementTest runs cleanly even with the DERBY-827 patch applied.

Derbyall and suites.All ran cleanly on Solaris 10, Java 1.6.

[Knut Anders Hatlen]

Committed derby-2597-1.diff with revision 535860.

[Knut Anders Hatlen]

Attaching patch which adds a JUnit fixture which tests whether an UpdateResultSet is able to detect changes in isolation level between executions. The test passes on trunk, but fails when the patch for DERBY-827 is applied (it continues with table-level locking after changing isolation level from serializable to read committed).

[Knut Anders Hatlen]

Committed derby-2597-2.diff with revision 536613.

[Knut Anders Hatlen]

Attaching derby-2597-3 which fixes the failure in testUpdateResultSetWithIsolation() when running with the DERBY-827 patch. What the patch does, is:

1) Move the static method UpdateResultSet.decodeLockMode() into DMLWriteResultSet and make it non-static. This makes it possible to add debug code that checks that it is only called when the {Update,Delete,Insert}ResultSet has been opened (to prevent calls at ResultSet construction time).

2) Move UpdateResultSet's call to decodeLockMode() from the constructor to open().

3) Make the NoRowsResultSetImpl class hierarchy maintain an isOpen variable that is set to true on open and to false on close. Previously, an isClosed variable was used, which was false until the first call to close(), after which it would be true forever even after the RS was reopened. This change was necessary to be able to assert that the result set had been opened in decodeLockMode().

With this patch, I think all result set classes are able to detect isolation level changes between executions.

Derbyall and suites.All ran cleanly with the patch (except the tests that currently fail in the Tinderbox). The patch is ready for review. Thanks.

[Knut Anders Hatlen]

Committed derby-2597-3 with revision 537128.