Some context: In scrollable updatable resultsets, we populate an
internal table with the following data:
<Position> <RowLocation> <RowUpdated> <RowDeleted> [<DataColumn>]+
Example layeout:
1 <1,10> false false 1,"a",3
2 <1,11> false false 2,"b",2
3 <1,12> false false 3,"c",9
When doing updateRow(), or deleteRow(), we use the RowLocation to
navigate to the row being updated.
Problem:
For holdable cursors, we will release the table intent lock when doing
commit on the transaction for the cursor.
The table intent lock, prevents the system from doing a compress of the
table, causing all RowLocations to be invalid. In addition, it prevents
reuse of RowLocation for deleted + purged rows.
In order to support holdable scrollable updatable cursors, we consider
having a service which allows the system to notify subscribers (i.e
cursors) that it has executed i.e a compress.
If the user then calls updateRow() or deleteRow(), we can then give an
exception like:
"The row could not be updated, because its location has been updated by
the system"
In addition, we consider having a reclaim of locks, so that immediatly
after a commit, the new transaction with the holdable cursor, may
reclaim the table intent lock. This will reduce the time period which
the system may compress the table, however not completely remove the
possibility of a compress.
Any comments on implementing such strategy ?
An alternative to this strategy, could be to go the other way: cursors
notify the system that it should not do compress.
I would appreciate feedback on this topic, especially if you find any
pitfalls with the proposed strategies, or have better alternatives.
Andreas
