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 <[EMAIL PROTECTED]
<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
