I think it is not about the wording in the specs. There are 2 distinct phaenomena:
- dirty-reading : possible only under READ_UNCOMMITED and its dirty-data of the reading transaction is the [i][u]temporary[/u][/i] data of a parallel transction (as perfectly described by P1 in the javadoc of lock())
- lost-updates : it's about checking that the initial version of some data you retrieved is not old at commit time, meaning other transaction commited newer versions meanwhile, so the transaction with the old version is not allowed to commit to avoid overwriting the newer values (in case it is doing an edit of that data, but you can still do the checking of the version even if you do only reading, just to be sure that the decisions you did based on the old value are not commited, as they could trigger inconssistencies). This is possible including under READ_COMMITED.
lock() javadoc says it's preventing dirty-reads. Dirty-reads are prevented by the isolation level itself: READ_COMMITED, with no contribuiton from lock(). Lock() is indeed useful for version checking, or otherwise put prevening lost-updates.
[Message sent by forum member 'vladbalan' (vladbalan)]
http://forums.java.net/jive/thread.jspa?messageID=316225