Skip to main content

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" 


Til said…
Can you upload an example to try this.
Jobinesh said…
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@@@");
Brother said…
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?
Jobinesh said…
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
This comment has been removed by the author.
Can you please help me out with this case:
Jobinesh said…
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
Tr0nx said…
This comment has been removed by the author.
Tr0nx said…
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.
vinay.polisetti said…
Thanks Jobinesh, this really helped.
sidhu said…
Thank you very much for the post.I had this similar error, found the issue was with VO. somehow it got messed up.
ADF OAF Tech said…
Thanks Jobinesh Sir it worked.
public void afterCommit(TransactionEvent transactionEvent) {

bala reddy said…
How this will work with SDO service interface?
you could try:
I think this is not so documented, but it may help you in order to refetch the row from database, then you may be able to perform some change and then commit.

Popular posts from this blog

How to set Bind Variable Values at runtime ?

In this post I'm sharing a couple of approaches for programmatically setting bind variables values at run time. This post is an attempt to explain 'When to use what ?'[ In case if you are familiar with 'Bind Variables' in ADF BC, please refer Section 5.10, Working with Bind Variables in Fusion Developer's Guide ]

1. Set the Bind Variable value using RowSet::setNamedWhereClauseParam(...)

You can use use the setNamedWhereClauseParam(...) method on the ViewObject interface (which extends oracle.jbo.RowSet) to set the value for bind variables. Please note this sets the value on default RowSet. In other words, this doesn't have any effect on the secondary RowSets that you/system generates.
ViewObject vo = am.findViewObject("EmployeesView1"); vo.setNamedWhereClauseParam("bindVarDeptId", new Number(10)); vo.executeQuery();
2. Set the Bind Variable value using ViewObject's VariableValueManager::setVariableValue(...)

VariableValueManager Ma…