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 Re: conflict detection strategies
Date Wed, 15 Feb 2006 15:42:07 GMT
Mike Matrigali wrote:
> If possible I would like to see a solution that does not require special
> messages sent back and forth between modules about state.

I am not entirely sure what restrictions you want to put on the design, 
it is a bit unclear to me.

I have considered some other solutions:

1. Change the locking behaviour, so that a table intent lock which is 
set by an updatable cursor, is kept as long as the cursor is open - this 
will ensure that the RowLocations are valid.

2. After a commit, we could clear all data in the internal table in the 
SUR. The problem with this approach is that the resultset would not 
necessarily be repopulated with the same data - it would be sensitive 
for changes across its own transactions commits, it would be highly 

3. Let the cursors notify the OnlineCompress module that it should fail 
any attempt to compress/defragment or purge the table.

More details on what I suggested yesterday:

The OnlineCompress class could provide an event mechanism, where 
subscribers (OnlineCompressListener) register themselves to listen to 
OnlineCompressEvents. The ScrollInsensitiveResultSet class could then 
implement the OnlineCompressListener interface, and register itself once 
it starts populating the table with RowLocations. The OnlineCompress 
class then simply notifies all listeners once it is doing defragment / 
The listeners should unregister themselves (i.e 
ScrollInsensitiveResultSet class could do it once it closes). The 
OnlineCompress class could use a WeakHashMap to put the listeners into, 
in case they are not well-behaved. I have not checked if derby already 
has event manager type of modules, if it does, I would attempt to reuse 

Please also let me know if any of the other alternatives seems better.


> Andreas Korneliussen wrote:
>>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