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] Commented: (DERBY-1361) positioned updates and deletes allowed after a commit without repositioning the cursor - if the table is indexed on the columns selected
Date Wed, 21 Jun 2006 08:29:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1361?page=comments#action_12417059 ] 

Andreas Korneliussen commented on DERBY-1361:
---------------------------------------------

For the scrollable case, I found two problems:

1. The network client will do a parsing of the SQL and reposition the cursor when there is
a positioned update (if it is a scrollable cursor). Since the cursor is repositioned, no exception
is thrown when doing it immediately after a commit.
The repositioning logic can be removed.

2. Scrollable cursors will not reposition the scancontroller of indexscans. This means that
the scancontroller for the index may be closed. Using the scancontroller to depend on this
logic does not seem sufficient.

I will go in another direction: on a commit, every activations will be notified. The activations
has references to a ResultSet, and they can notify the resultsets that they should be positioned
between the current row and the next row (this can be done by setting currentRow=null)

As for the two different error messages, I think that this change may force me to choose one
of these. It does not seem to be entirely deterministic when I get one and not the other.
I think the correct message is the one with SQLSTate 24000.


> positioned updates and deletes allowed after a commit without repositioning the cursor
- if the table is indexed on the columns selected
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1361
>          URL: http://issues.apache.org/jira/browse/DERBY-1361
>      Project: Derby
>         Type: Bug

>   Components: JDBC
>     Versions: 10.2.0.0
>  Environment: Java 1.4
>     Reporter: Andreas Korneliussen
>     Assignee: Andreas Korneliussen

>
> After a commit, the cursor should be positioned before the next row (not on a row). However
in Derby 10.2, I now see the following behavior if the table has an index on the selected
columns:
> ij> create table t (id int primary key);
> ij> commit;
> ij> insert into t values 1,2,3,4,5,6,7,8,9;
> 9 rows inserted/updated/deleted
> ij> commit;
> ij> get cursor c1 as 'select * from t for update';
> ij> next c1;
> ID         
> -----------
> 1          
> ij> commit;
> ij> update t set id=id+1000 where current of c1;
> 1 row inserted/updated/deleted
> ij> commit;
> ij> update t set id=id+1000 where current of c1;
> 1 row inserted/updated/deleted
> ij> 
> The expected behavior is  that the UPDATE .. WHERE CURRENT OF fails with:
> ERROR 24000: Invalid cursor state - no current row.
> The problem applies to both scrollable and forward-only updatable cursors.
> Note: If the table is created *without* the index, I do see the expected behavior.
> I am marking this as a regression, since this issue is not reproducible on older, released
versions of derby (I have tested with 10.1.2.1).

-- 
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