db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik" <Dag.Wan...@Sun.COM>
Subject Redundant locking when skipping rows in scrollable result set
Date Thu, 03 Nov 2005 17:40:27 GMT


I am wondering if this might be a candidate for improvement. Here
is the case which shows what's going on (see also repro enclosed):

Transaction 1 has an update lock on a row. Transaction 2 opens a
scrollable (read-only) result set which has an underlying "FOR UPDATE"
query, so update locks will be used for this transaction, too.  Next,
we position that result set of trans 2 to a row *past* the locked row
of trans 1, using ResultSet#absolute. This is the first use of this
result set, so each qualifying row we move past will be read (and momentarily
update locked!), then inserted into the hash table for later scrolling.
In the repro, in the positioning, trans 2 locks on trans 1's update
lock for the row we move past.

It would seem that only the destination row indicated by the
absolute() requires the lock.

This seems to be a candidate for improvement. The same problem occurs
for ResultSet#relative and ResultSet#last too, most likely.

Once all rows have been read into the cache, later positioning will
not have this problem, so it is a corner case, but I thought
I'd mention it. It will be more likely to occur when scrollable
result sets are made updatable.


View raw message