db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: conflict detection strategies
Date Tue, 14 Feb 2006 18:46:25 GMT
I have not been following the scrollable updatable result set work,
I had assumed that the work would be similar to the other resultset
work in Derby with no special requirements from the store.  Is there
a proposed design for this project that I should go look at?  I looked
at the doc associated with DERBY-690, but there are a lot of suggested
approaches - but not clear which choices have been made.

There is a lot of discussion about using the current support for
update where current of.  In the current system how does the system
translate a user request for an update where current of, to the
actual update of the row.  Does it currently use RowLocation?

If possible I would like to see a solution that does not require special
messages sent back and forth between modules about state.

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.
> 
> 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
> 

Mime
View raw message