db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Korneliussen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Closed: (DERBY-1249) cursor operation conflict incorrectly handled in scrollable updatable resultsets
Date Tue, 23 May 2006 13:46:30 GMT
     [ 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


Mime
View raw message