Optimistic locking is definitely preferred over pessimistic locking.

Even more, JPA 1.0's pessimistic locking wasn't complete yet IIRC, as 
that's one of the things that JPA 2.0 improves.
Optimistic pretty much does what it needs in JPA 1.0: slap in a
   @Version
   private int version;
and off you go.

At my company we purely use optimistic locking, except for 1 or 2 tables.
With pessimistic locking, it usually boils down to having to show 
read-only records to the user and ask him if he wants to edit it (=lock) 
before he can change it.

With optimistic locking, you're never sure that your commit will work.
On the other hand, you are never sure your commit will work:
- they could have deleted the B you reference in A (so not just lock A 
but B too)
- the POJO is using hibernate validator and that validation fails
- a property is not unique (notice that only the database can check that 
reliably, you cannot unless you use isolation level serialized, which is 
useless if you have more then 2 users.)
- ...
Things fail, get used it. Optimistic in practice rarely gives stale 
exceptions (if you don't have a 
everything-updates-a-singleton-record-too anti-pattern, which would be 
horrible with pessimistic locking too).

With kind regards,
Geoffrey De Smet

Mark Proctor schreef: