> the current Derby semantics (releasing
the update lock once a next() is executed), isn't very helpful.
Even in read-committed isolation level, it still seems like it might be useful to be able to control the lock-mode on the current row. If I have an read-committed transaction which reads through many rows, and chooses to update a subset of them, being able to communicate to the DB that I'd like an update-mode lock when I read the record, to be either (a) released when I do Next or (b) promoted to exclusive-mode if I happen to update this record, seems like a useful behavior to me. That is, I think that update-mode locks can be useful in reducing deadlock, and I think that's true even when running at read-committed isolation level. thanks, bryan
