Friday, October 9, 2009

Open Locks in optimistic locking bug !!!

Open Locks in optimistic locking bug !!!

Yes it is possible, it was happening in our application and could not imagine why.
After research we found out that it was in the CustomDBTransactionImpl.
We use it to override doCommit in order to do staff after all data are posted but not yet committed according to :
Fusion Developer's Guide for Oracle ADF, D ADF Equivalents of Common Oracle Forms Triggers:

Execute code after Forms has "posted" all necessary rows to the database, but before issuing the data commit to end the transaction

If you want a single block of code for the whole transaction, you can override the doCommit() method in a custom DBTransactionImpl object and write code before calling the super.

I managed to reproduce it in a simple test case.

I just have Departments entity and view and an application module with CustomDatabaseTransactionFactory. In CustomDBTransactionImpl I override doCommit and throw an exception:

protected void doCommit() {
if (true){
throw new JboException("Exception in doCommit");

I run the application, make a change and press commit. I get the error:

Now the row is locked in the database!!!!

I run a new instance of the application i make a change and try to commit and I get:

If I try to do rollback before I throw the exception then the locks are lost of course but also all the changes made on page.

Is this a bug?
If not, is there an other way to check and throw exception, after data are posted to database and before commit, without locking?


  1. Hi,

    It seems logical - if you throw error, transaction is not closed and lock remains.


  2. Thanks Andrejus.
    The issue is that:

    It does not happen the same if you do it after doDML of an entity, even though row is posted.

    It doesn't happen if 2 rows are posted and the 3rd has a constraint exception.

    I guess some database rollback is executed without rolling back the entity.

    I am just looking for a way to do it after all doDMLs are executed.

  3. Solution described in

  4. How many of your Lock related Posts are proven to be a bug?