Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Wed, 23 Aug 2006 22:24:12 +0200
From: Andreas Korneliussen <Andreas.Korneliussen@Sun.COM>
Subject: Re: Question on SUR and U lock.
In-reply-to: <44EC9300.2080007@gmail.com>
Sender: Andreas.Korneliussen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <44ECB96C.3070805@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <44EC9300.2080007@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)

Sunitha Kambhampati wrote:
> I was doing some testing for SUR and had a question about the expected
> behavior.
> 
> The SUR related doc on
> http://db.apache.org/derby/docs/dev/devguide/rdevconceptssur.html  says
> "The row which the cursor is positioned on is locked, however once it
> moves to another row,
> the lock may be released depending on transaction isolation level."
> 
> In my test (isolation level is default - RC),   I have a SUR, resultset
> has 1000 rows,  all rows are materialized by calling absolute(-1). After
> this the cursor is positioned before the first row by calling
> beforeFirst().  Printing the locktable shows
> 1)a IX lock on the table,  which is fine.
> 2)U row lock on the table. Why do we hold the U lock when the cursor is
> not positioned on any row ?.

Hi,
Thanks for testing SUR. This is not as it was intendended to be, and I
have already filed a bug report:

DERBY-1696 "transaction may sometimes keep lock on a row after moving
off the resultset in scrollable updatable resultset"

Hopefully it can be fixed for 10.2

Regards
Andreas