Fernanda Pizzorno (JIRA) wrote: > Read-uncommited isolation level does aquire locks for updatable forward-only > result sets, the same behavior has been kept on scrollable insensitve > updatable result sets.
Hmmm, this means such ResultSets are not running at read-uncommitted isolation level, they are running at read-committed isolation level. I understand this is existing behaviour, I wonder if it arises due to SELECT's FOR UPDATE causing this locking behaviour. Customers in the past have complained about any locks obtained in read-uncommitted mode, it might be suprising for them to have a read-uncommitted ResultSet blocked by other transactions. I wonder if, at least for scrollable updateable ResultSets, we should disallow read-uncommitted isolation level, it may be a cleaner way forward thean implementing them as read-committed and then have concerns in the future about backwards compatibility if we ever need to implement them correctly. Maybe the more precise statement is disallow updateRow and deleteRow when the isolation level is read un-committed. insertRow seems fine. Forward-only updateable read-uncommitted ResultSets ideally should be disallowed as well, but that might cause backward compatibility issues. Dan.
