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
Hi,

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.

--Andreas

---------------------
From: Mike Matrigali <mikem_app@... 
<http://gmane.org/get-address.php?address=mikem%5fapp%2drphTv4pjVZMJGwgDXS7ZQA%40public.gmane.org>>
Subject: Re: conflict detection strategies 
<http://news.gmane.org/find-root.php?message_id=%3c43F22581.7090600%40sbcglobal.net%3e>
Newsgroups: gmane.comp.apache.db.derby.devel 
<http://news.gmane.org/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



Mime
View raw message