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.
