db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4778) In Client mode, holdable resultset cursor used in positioned update shouldn't access row with autocommit=true
Date Wed, 18 Aug 2010 13:50:16 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899847#action_12899847

Knut Anders Hatlen commented on DERBY-4778:

I'm not so sure that embedded behaves correctly in this case. There's nothing that should
make the transaction auto-commit between "next scrollCursor" and the update statement, as
far as I can see.

One way to start may be to find out where the call to commit comes from, so that we can understand
better what's going on.

> In Client mode, holdable resultset cursor used in positioned update shouldn't access
row with autocommit=true
> -------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-4778
>                 URL: https://issues.apache.org/jira/browse/DERBY-4778
>             Project: Derby
>          Issue Type: Bug
>            Reporter: Yun Lee
> Consider sql snippet below, which is from the tenth test in holdCursorIJ.sql:
> create table t1(c11 int, c12 int);
> insert into t1 values(1,1);
> insert into t1 values(2,2);
> autocommit on;
> get with hold cursor scrollCursor as 'select * from t1 for update of c12';
> next scrollCursor;
> update t1 set c12=c12+1 where current of scrollCursor;
> -- clean up.
> close scrollCursor;
> look at 'update' line, in Embed mode, 'ERROR 24000: Invalid cursor state - no current
row.' will be thrown, it's correct, just like SQL standard, and this behaviour is discussed
in DERBY-610.
> 'The SQL standard 2003, Part 2: Foundation
> (SQL/Foundation) p 827:
> > 6) If CR is a holdable cursor and a <fetch statement>has not been
> > issued against CR within the current SQL- transaction,then an
> > exception condition is raised: "invalid cursor state".
> That is, a positioning operation is required before the row can be
> updated or deleted. Derby implements rowUpdate and rowDelete using
> positioned cursor operations and has the same limitation, and will
> give the same exception for forward only, updatable result sets. For
> Scrollable, updatable insensitive result sets being implemented as
> DERBY-690 and DERBY-775, the behavior should be the same. JDBC
> doesn't address this requirement, as far as I can tell.'
> However, in Client mode, it will succeed. It's not correct!

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

View raw message