[DERBY-1249] cursor operation conflict incorrectly handled in scrollable updatable resultsets

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 10.2.1.6
• Fix Version/s: 10.2.1.6
• Component/s: JDBC, Network Client
• Assignee: Andreas Korneliussen
• Reporter: Andreas Korneliussen
• Created: 24/Apr/06 21:05
• Updated: 23/May/06 20:45
• Resolved: 23/May/06 20:45

Description

In a scroll insensitive updatable resultset:

When using updateRow() or deleteRow() to update the current row, and the row has been deleted by another committed transaction or by another statement in its own transaction, the ResultSet fails to fully detect that there has been a conflict, and that the row has not been updated. The ResultSet get a warning (CURSOR_OPERATION_CONFLICT), however the following methods get unexpected results:
ResultSet.rowUpdated(): returns true. Instead it should return false, since the updateRow() updated 0 rows, and the row has not been updated by the resultset.
ResultSet.getXXX(..): returns the new value set by updateXXX(..), however 0 rows were updated, and getXXX(..) should return the old value.
ResultSet.rowDeleted(): returns true (after a deleteRow() which deleted 0 rows). It should return false, since the row was not deleted by the resultset itself, and insensitive resultsets do not detect changes made by others.

A fix for this bug could be to use the updatecount, and cancel the row updates if it is 0.