db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: conflict detection strategies
Date Thu, 16 Feb 2006 15:52:43 GMT
Andreas Korneliussen wrote:

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


Was this posted, the more detailed solution?

There was a little more detail on a proposed interaction with online
compress, but I think that is based upon a whole lot of design thinking
and assumptions which has not made it to list.

I'd assumed you meant you were going to describe your proposed full
solution to SUR, I'm interested to know your approach works with the
various isolation levels, how you handle deleting the rows, how
holdability is supported, etc. And if during working on this you had to
work out how scrollable read-only cursors are implemented, adding that
as background would be excellent. Great knowledge to add to the
community. Don't assume reviewers know how things work today, provide as
much information as you know.

Thanks,
Dan.



Mime
View raw message