Andreas Korneliussen wrote:
Mike Matrigali wrote:
<snip>
I would think there are multiple ways of adressing this issue:
1 We could make the store graciously handle the situation if the
RowLocation points to a deleted+purged row, by returning false if the
RowLocation is invalid, (and from the caller we can give an exception)
This may not be good option, because purged row location can
potentially be used by an another insert from a different
transaction.
2 Or we could make all scrollable updatable resultsets set read-locks or
updatelocks on every row, for all isolation levels (including
read-uncommitted)
Sounds like a good idea.
3 Or we could make purging require a table level X lock, instead of row
locks
No, this can lead to real concurrency issues, if application is doing
lot of deletes in parallel to other operations.
Thanks
-suresht
