You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Andreas Korneliussen (JIRA)" <de...@db.apache.org> on 2006/04/24 16:07:06 UTC
[jira] Created: (DERBY-1249) cursor operation conflict incorrectly
handled in scrollable updatable resultsets
cursor operation conflict incorrectly handled in scrollable updatable resultsets
--------------------------------------------------------------------------------
Key: DERBY-1249
URL: http://issues.apache.org/jira/browse/DERBY-1249
Project: Derby
Type: Bug
Components: JDBC, Network Client
Versions: 10.2.0.0
Reporter: Andreas Korneliussen
Assigned to: Andreas Korneliussen
Priority: Minor
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1249) cursor operation conflict incorrectly
handled in scrollable updatable resultsets
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1249?page=all ]
Andreas Korneliussen closed DERBY-1249:
---------------------------------------
Fix Version: 10.2.0.0
Resolution: Fixed
Fixed as part of DERBY-1251. Closing bug as fixed.
> cursor operation conflict incorrectly handled in scrollable updatable resultsets
> --------------------------------------------------------------------------------
>
> Key: DERBY-1249
> URL: http://issues.apache.org/jira/browse/DERBY-1249
> Project: Derby
> Type: Bug
> Components: JDBC, Network Client
> Versions: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
> Fix For: 10.2.0.0
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira