db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject conflict detection strategies
Date Tue, 14 Feb 2006 11:28:54 GMT
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.

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.


View raw message