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 Tue, 14 Feb 2006 20:07:53 GMT

The implementation of SUR  just builds on the existing scrollable 
resultsets, which collects all rows into a table. We have extended this 
table to also contain RowLocation and some metadata.
This means we do not need to change the store module to navigate 
backward etc - no changes in the store module.

Updatable cursors in derby  uses RowLocation, however the row is 
guaranteed to be locked (current row has update lock, I think, 
regardless of isolation level).
As for holdable cursors, forward only updatable cursors require the user 
to navigate to the next row after a commit, thereby getting a new 
rowlocation, on a row which is locked.

I will propose a more detailed solution tomorrow, so it becomes more 
clear, and less mysterious, what I really propose :-)
Any other suggestions are of course welcome.


From: Mike Matrigali <mikem_app@... 
Subject: Re: conflict detection strategies 
Newsgroups: gmane.comp.apache.db.derby.devel 
Date: 2006-02-14 18:46:25 GMT (59 minutes ago)

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

View raw message