[
https://issues.apache.org/jira/browse/DERBY-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-1799:
--------------------------------------
Issue & fix info: [Repro attached]
Urgency: Normal
Triaged for 10.5.2.
> SUR: current row not locked when renavigating to it, in queries with indexes
> ----------------------------------------------------------------------------
>
> Key: DERBY-1799
> URL: https://issues.apache.org/jira/browse/DERBY-1799
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4
> Reporter: Andreas Korneliussen
> Attachments: derby-1799.diff, derby-1799.stat
>
>
> This problem is detected in transactions with isolation level
> read-committed/read-uncommitted.
> We have a table (T) which has a primary key (a), and a query which does
> "select A from T" (an indexed select)
> If the result set is scrollable updatable, we expect the current row to be
> locked with an update lock. This does not seem to happen when repositioning
> to a row which has been already been fetched previously.
> The result is that either the wrong row is locked, or if the result set has
> been on after last position, no row is locked.
> Output from ij:
> ij> get scroll insensitive cursor c1 as 'select a from t for update';
> ij> next c1;
> A
> -----------
> 1
> ij> select * from SYSCS_DIAG.LOCK_TABLE;
> XID |TYPE |MODE|TABLENAME
>
> |LOCKNAME |STATE|TABLETYPE|LOCK&|INDEXNAME
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 243 |ROW |U |T
>
> |(1,7) |GRANT|T |1 |NULL
>
>
> 243 |ROW |S |T
>
> |(1,1) |GRANT|T |1 |SQL060901103455010
>
>
> 243 |TABLE|IX |T
>
> |Tablelock |GRANT|T |4 |NULL
>
>
> 3 rows selected
> ij> after last c1;
> No current row
> ij> previous c1;
> A
> -----------
> 3
> ij> select * from SYSCS_DIAG.LOCK_TABLE;
> XID |TYPE |MODE|TABLENAME
>
> |LOCKNAME |STATE|TABLETYPE|LOCK&|INDEXNAME
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 243 |TABLE|IX |T
>
> |Tablelock |GRANT|T |4 |NULL
>
>
> 1 row selected
> The last select shows that no row is locked at this point, however we expect
> one row to be locked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
