db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4184) Calling deleteRow() on a ResultSet that has been commited throws no error
Date Mon, 27 Apr 2009 23:39:30 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mike Matrigali updated DERBY-4184:
----------------------------------


I believe the current behavior is correct with respect to "held" cursors.  Maybe someone can
quote the exact standard.  Basically at commit time a held cursor is not positioned on the
current row, it is said to be positioned before the next row.  Thus there is a very limited
number of valid operations on a cursor 
following a commit - i think it is just next and close.  This may not be intuitive but I believe
it implements the standard and the behavior is well defined, and allows an easier non-lock
holding implementation than guaranteeing the "current" row is available.  

My experience is with the original cursor implementation, not with scrollable cursors.

> Calling deleteRow() on a ResultSet that has been commited throws no error
> -------------------------------------------------------------------------
>
>                 Key: DERBY-4184
>                 URL: https://issues.apache.org/jira/browse/DERBY-4184
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Server
>    Affects Versions: 10.6.0.0
>         Environment: Not relevant.
>            Reporter: Tiago R. Espinha
>            Priority: Minor
>         Attachments: ReproHoldCursorBug.java
>
>
> This issue was originally found on DERBY-3839.
> The steps to get this error happening are as follows:
> 1) Set auto commit to false
> 2) Create a Statement with the following parameters:
> ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_UPDATABLE and ResultSet.HOLD_CURSORS_OVER_COMMIT
> 3) Create a ResultSet by having a SELECT on an executeQuery() on a table with at least
one row.
> 4) Do a next(); on the ResultSet. Then commit() and try to deleteRow() on the ResultSet.
> According to holdCursorJDBC30.out, the deleteRow() should throw an 'Invalid cursor state
- no current row' but it doesn't, not when using Java code.
> The problem here is the ResultSet.CONCUR_UPDATABLE. By setting this property, the ResultSet
checks that the property is different from CONCUR_READ_ONLY and doesn't do a proper check
on checkForUpdatableResultSet(). Without this check, the deleteRow() executes successfully
BUT, the row does NOT get deleted.
> After talking about this with Kathey, we agreed that the exception should always happen.
If an exception isn't thrown and the row isn't deleted, then this is certainly misleading

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message