OptUpdate Locking Mode in ADF 11g PS3 and Centralized ADF BC Config

Hey, exciting news - JDeveloper 11g PS3, SOA 11g PS3 and WebLogic 11g PS3 are available. But there are no WebCenter 11g PS3 yet, Ok  - we can wait (we expect really good quality release). Download new JDeveloper 11g PS3 - download page. I didn't see anywhere separate download of ADF 11g PS3 runtime for standalone WebLogic deployment, but you can use the same JDeveloper 11g PS3 install wizard for this purpose. In order to get up to speed with new features of ADF 11g PS3, I recommend to read What's New sections from available developer guides - ADF Developer Guide and ADF Web Developer Guide. There are many new interesting features, one of them - additional locking mode (Optupdate). This locking mode works without executing database lock on data change. Previous ADF 11g releases were working with two locking modes - Pessimistic and Optimistic.

Download sample application - OptUpdateADF.zip.

Some of the ADF Business Components configuration settings can be set now from one central place - adf-config.xml file. Before researching new Optupdate locking, let's look into behavior without any locking mode at all. Locking mode - None:

One user is editing FirstName field - saving change:

Update and Commit are done without any locking:

There is another user, who is editing the same record at the same time - changing and saving LastName field:

Even the same record was modified by another user - we still can commit without any warning:

We can change and update even the same field, previously modified by another user - FirstName:

There will be no errors, data will be updated and saved successfully:

Now we change Locking Mode to Optupdate, new Locking Mode available in PS3:

Let's change FirstName field and save:

Data was saved without executing lock, similar as with no locking mode:

Second user work with the same record, updates and saves LastName field:

RowNoFound exception is generated:

ADF reports error about not found row:

In case of Pessimistic or Optimistic lockings, user would be informed about data changed by another user. In this case, user will be forced to refresh VO data, for example by clicking Undo button. It seems like Optupdate locking mode is useful, when there is no concurrency and mostly only single user is doing updates. However, we still want to prevent possible concurrency cases from simultaneous updates (as it happens in no locking mode).

Press Undo button to refresh VO with latest data:

Now this user can change and save data as well:

Let's test how it works when validation error happens. One user is changing foreign key value and gets validation error:

The same as with Optimistic locking, while validation error is not fixed, still other user will be able to change and save data (because lock is not set by the first user):