Pessimistic Locking in Oracle
Discussion
Oracle supports row-level pessimistic locking. By default EOF uses Oracle's SELECT FOR UPDATE without the NO WAIT clause. This can be changed by calling OracleSQLExpression's setUseNoWaitLocks class method.
The standard SELECT FOR UPDATE lock will cause all the UPDATE or SELECT FOR UPDATE statements from other database connections to block until a commit, rollback, or a deadlock exception occurs. A deadlock exception occurs when one user has row A locked and is trying to lock row B, while another user has row B locked and is trying to lock row A. In this case, Oracle disables one of the users locks while letting the other user lock both rows.
When using the SELECT FOR UPDATE NO WAIT locks, Oracle will cause an exception whenever a locked row is selected. This can be useful if you don't want to block a user for an indefinite amount of time.
Also note that a SELECT statement without the FOR UPDATE clause will always work. This can be somewhat dangerous. For example, suppose user A fetches an object without locking it. User B fetches the object with locking and saves it. User A then modifies the object and again saves it, overwriting what user B has done. The only way this can be avoided is to use a consistent locking strategy.