Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43F49FCB.5030108@apache.org>
Date: Thu, 16 Feb 2006 07:52:43 -0800
From: Daniel John Debrunner <djd@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: conflict detection strategies
References: <43F1BEF6.6020301@sun.com> <43F23899.8020608@sun.com>
In-Reply-To: <43F23899.8020608@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.