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.
