Hi,
We are planning on using RowLocation to position the cursor when doing
scrollable updatable cursors (i.e when navigating backwards in the
resultset) - see
http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/10028 for
more details.
The fact that the RowLocation could become invalid, do worry me a bit.
I did a test on a simple select statement, using transaction level
read-uncommitted.
T1: select * from testtable
Then (before doing commit) I called on another connection:
T2: call SYSCS_UTIL.SYSCS_COMPRESS_TABLE("APP", "TESTTABLE", 0)
T2: Got exception:The exception 'SQL Exception: A lock could not be
obtained within the time requested' was thrown while evaluating an
expression.
So even in read-uncommitted mode, a lock intent level lock on the table
is set (good), and it seems to be held until I close the resultset or
commit the transaction T1.
The problem I then see is for cursors that are held over commit
(ResultSet.HOLD_CURSORS_OVER_COMMIT). Maybe we should not support it for
scrollable updatable resultsets.
Anyway , we would really appreciate to get some comments on the
specification Dag sent out two days ago, to ensure that we are on the
right track.
Thanks
-- Andreas
Mike Matrigali wrote:
Assuming row is not deleted, the question can only be answered
knowing the isolation level. Basically the RowLocation can only
be counted on while a lock intent level lock is held on the table.
Intent table locks may be released as soon as a statement is
completed, or may be held to end of transaction depending on
the type of statement and type of isolation level.
The thing that may move an existing row in a heap are the compress
table system procedures.
If a row is deleted then there are other factors.
Rick Hillegas wrote:
Hello Store experts,
How long is a RowLocation in a Heap good for? Provided that the row is
not deleted, can you count on its RowLocation reliably identifying the
row for the duration of a Statement, a Transaction, a Connection?
Forever?
Thanks,
-Rick
