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: Mon, 14 Nov 2005 10:37:32 +0100
From: Andreas Korneliussen <Andreas.Korneliussen@Sun.COM>
Subject: Re: RowLocation lifetime
In-reply-to: <4374FCA8.4050008@sbcglobal.net>
To: derby-dev@db.apache.org
Reply-to: Andreas.Korneliussen@Sun.COM
Message-id: <43785ADC.9020306@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
References: <43729B2D.9070502@sun.com> <43729E46.4020105@sbcglobal.net>
 <43737D0C.1000108@sun.com> <437397DA.2050306@sbcglobal.net>
 <4374DD56.7000701@sun.com> <4374EE09.20601@gmail.com>
 <4374F329.7070006@debrunners.com> <4374FCA8.4050008@sbcglobal.net>

Mike Matrigali wrote:
> i get confused when speaking about isolation level, update/read only
> result sets, and underlying sql query of the result set.  I don't
> know if one scrollable result sets are dependent on some sort of
> isolation level.
> 
> With respect to straight embedded server execution of SQL, it is fine to 
> run with
> read-uncommitted level - but any actual update done on a row will get
> an X lock held to end transaction.  At least from this level an SQL
> operation is never failed dependent on the isolation level.
> 
> I don't remember if U locks are requested in read uncommitted mode,
> but definitely X locks are requested when the actual update is done.
> 
> Note that all discussions of locking should specify under which 
> isolation level the system is running.  I assumed read commited for
> the below discussion as it is the default.
> 

The discussion was intended for  read-committed and read-uncommitted, 
since for other isolation levels, the rows for which we use the 
RowLocation would be locked, and cannot be deleted or purged by another 
transaction. Also, if we delete the row in our own transaction, it will 
not be purged, since it is locked with an exclusive lock.

I think you are allowed to do updates in read-uncommitted, however when 
you read, you do not set read-locks, so you can read uncommitted  data.

Andreas


> Daniel John Debrunner wrote:
> 
>>> Andreas Korneliussen wrote:
>>
>>
>>
>>>> 2 Or we could make all scrollable updatable resultsets set read-locks
>>>> or  updatelocks on every row, for all isolation levels (including
>>>> read-uncommitted)
>>
>>
>>
>> I think updates are not allowed in read-uncommitted mode, so we should
>> not be getting locks in read-uncommitted.
>>
>> Dan.
>>
>>
>>
>>
>>
>