Yet another reason for "JBO-25014: Another user has changed the row with primary key oracle.jbo.Key"

I've discussed one possible (tricky) reason for JBO-25014 error in one of my previous post - 'What you may need to know about Nested Application Module' . Recently I noticed yet another interesting reason for the above said JBO-25014 error. Let me summarize the same for the benefit of the ADF community.

Use case

This use case has two view objects - SimpleEmployeeViewObject and DetailedEmployeeViewObject, both are based on the same entity object - EmployeeEntityObject. A specific business functionality is implemented using the above ViewObjects as listed below.

1. SimpleEmployeeViewObject queries the DB by calling SimpleEmployeeViewObject.executeQuery(). The code doesn't fetch any records at this stage(I meant that, this code just got the executeQuery call, no iteration logic). However this call results in the creation of result set/cursor, and leaves it opened.

2. Then, DetailedEmployeeViewObject queries by calling DetailedEmployeeViewObject.executeQuery(). Here the code fetches set of records and modifies the record with EmployeeID = 101.

3. Commits the Transaction, and then call DetailedEmployeeViewObject.clearCache()

4. As a next step, SimpleEmployeeViewObject tries to get the employee record with EmployeeID = 101. Note that, SimpleEmployeeViewObject does not call executeQuery here, instead queries the RowSet(retrieved at Step 1) for the record. This may return the stale row from the opened cursor, and apparently this row doesn't reflect the modified attributes from database (committed at Step 3). This step modifies the retrieved record and commits the transaction.

5. At Step 4, the 'commit' operation may tries to locks the row, it compares the original values of all the persistent attributes in the entity cache as they were last retrieved from the database with the values of those attributes just retrieved from the database during the lock operation. Apparently this may throw "JBO-25014: Another user has changed the row with primary key oracle.jbo.Key[101]" as the entity object is populated with a stale row set.

What is the solution ?

The solution is to close the opened cursor(result set) having the stale data after the commit at Step3 ( before the next transaction). Please note that, ADF BC runtime closes the result set/curosr as part of Transaction::rollback(). However Transaction::commit() doesn't touch the opened cursors, by default.

The easiest work around here is to call SimpleEmployeeViewObject.executeQuery() before step4. Either you can do it through a explicit call or you can move this call to SimpleEmployeeViewObjectImpl::afterCommit(TransactionEvent event) method.

Re-querying all View Objects on commit

On a related note, you can configure a specific Application Module to refresh all its View Objects after the commit of a transaction by setting RequeryOnCommit="true". This setting may cause all the 'queried' View Objects of the Application Module to requery/refresh after the commit. This setting also may help you to solve error that we discussed in this post (You should be careful while keeping this ON as this result in expensive requery of all View Objects belonging to the Application Module).

  ClearCacheOnRollback="true" RequeryOnCommit="true" 


  1. Can you upload an example to try this.

  2. Til, This is a very odd scenario. Lots of factors needs to be aligned to reproduce the issue :) Bottom line is that, You don't need to worry on this, if you never happened to encounter this error. However, just for the sake of answering this query, I copying the relevant test code below for your ref(Thanks to Sekhar Korupolu for sharing this)

    ViewObject simpleEmployee = getSimpleEmployeeViewObject();
    ViewObjectImpl detailedEmployeeVO = getDetailedEmployeeViewObject();
    Key k = detailedEmployeeVO.first().getKey();
    detailedEmployeeVO.first().setAttribute("LastName", "ModifiedOne");
    DBTransactionImpl txn =

    oracle.jbo.server.EntityCache ec =
    while (ec.getForAltKey(0, k) != null) {
    try {
    } catch (Exception e) {
    simpleEmployee.first().setAttribute("LastName", "ModifiedOne@@@");

  3. Hi Jobinesh,

    This is regarding a problem with my project. The application behaves unexpectedly on a button click(not necessarily same button) event and a particular screen appears. This is found on different modules. Could you pls help me in identifying the root cause?

  4. Well, there are multiple reasons for this.
    One common root cause is that some EO may have attributes populated by DB trigger or sequence which is not getting refreshed back on specif EO instance. You may need to turn on 'Refresh After' flag for the EO in this case. Another reason is detailed in one of my previous case.
    Also check this link , this contains some sample code to identify the attribute that triggers this exception

  5. This comment has been removed by the author.

  6. Can you please help me out with this case:

  7. Divya,
    If the issues doesn't happen after re executing the query, then the root cause could be same as described in this blog. Probably you may need to re-execute VO and work around other issues

  8. This comment has been removed by the author.

  9. My solution to the problem was to add the following line to the Application Module:

    ClearCacheOnCommit = "true"

    I was as follows:

    AppModule xmlns = ""
    Name = "UtdAM"
    Version = ""
    ClearCacheOnRollback = "true"
    ClearCacheOnCommit = "true"

    I hope they serve.

  10. Thank you very much for the post.I had this similar error, found the issue was with VO. somehow it got messed up.

  11. Thanks Jobinesh Sir it worked.
    public void afterCommit(TransactionEvent transactionEvent) {


  12. How this will work with SDO service interface?


Post a Comment