db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: RowLocation lifetime
Date Fri, 11 Nov 2005 20:18:48 GMT
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.

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


Mime
View raw message