While doing Oracle ADF 11g training during this week, we were discussing with students about Optimistic and Pessimistic locking support in ADF BC. Actually, while available documentation gives you good insight into theoretical side of locking mechanism, its still quite hard to understand how it really works and when we should apply Optimistic or Pessimistic locking. I have prepared sample application, where I'm describing differences between those two.
Download - OptimisticPessimisticLocking.zip application, it is configured by me to work in Optimistic locking mode. Let's switch to Pessimistic locking (default one), you can do this through ADF BC application module settings:
In order to test locking behavior, we need to simulate multiple users - just open sample application with two separate browsers:
We change data in the second browser (second user), press Save button. Then we go to the first browser (first user), modify data and press Save - error about concurrent data modification in current will be shown:
And now is very important part - let's assume that user in the first browser will wait and will not try to save or undo his changes. This basically means, in Pessimistic locking case, database lock from the first user still will remain in database. Now, if second user will go to modify same record and will try to save it:
The second user will get error about database lock - user will be stuck in current record:
The second user will be forced to wait until first user will Save or Undo his changes in order to proceed with data commit. Another option for the second user - Undo his change in the current row and proceed with other rows editing. When the first user will close his transaction, the second one will be able to save his changes for previously locked record as well:
Now we will see how it works in Optimistic mode:
The second user is changing data, committing it and then first user is doing change in the same row and trying to save it - error about concurrent modification will be generated:
However in Optimistic locking case, the first user will not hold database lock and second user will be able to continue his work (with the same or other records):
At the same time, first user will be able to press Save button second time, and his data will be committed.