As described in the Oracle documentation here, ADF BC uses its own row consistency enforcement mechanism :
4.10.11 How to Protect Against Losing Simultaneously Updated Data
At runtime, the framework provides automatic "lost update" detection for entity objects to ensure that a user cannot unknowingly modify data that another user has updated and committed in the meantime. Typically, this check is performed by comparing the original values of each persistent entity attribute against the corresponding current column values in the database at the time the underlying row is locked. Before updating a row, the entity object verifies that the row to be updated is still consistent with the current state of the database. If the row and database state are inconsistent, then the entity object raises the RowInconsistentException.
You can make the lost update detection more efficient by identifying any attributes of your entity whose values you know will be updated whenever the entity is modified. Typical candidates include a version number column or an updated date column in the row. The change-indicator attribute's value might be assigned by a database trigger you've written and refreshed in the entity object, because you selected the Refresh on Insert or Refresh on Update option (on the Details tab). Alternatively, you can indicate that the entity object should manage updating the change-indicator attribute's value using the history attribute feature described in Section 4.10.12, "How to Track Created and Modified Dates Using the History Column." To detect whether the row has been modified since the user queried it in the most efficient way, select the Change Indicator option to compare only the change-indicator attribute values.
ADF BC doesn’t use the database locking mechanism to avoid other users modifying the data. It can either check all the record values for change or verify a change indicator attribute :
- Comparing value :
When your user commits its change, ADF BC compares the value of the originally fetched record, without any modifications, with the current value of this same record.
If any of the column’s value isn’t the same, the oracle.jbo.RowInconsistentException JBO-25014 : Another User Have changed the Row with Primary Key error occurs.
- Change Indicator attribute :
If your database view contains a version column, you can check the change indicator option of the version attribute inside the ADF BC Entity Object.
This error can then occur for multiple reasons :
- The record you are trying to update in your ADF application has been updated outside of the application scope. (Usually, a Database Trigger modifying a value on update)
- Ensure the data isn’t being modified outside of the application.
- When you use an “Expert Mode” View Object with default value attributes. (e.g., Comparing a Default Value with the column value will always give difference if the default value is a current time TimeStamp)
- Fix it by removing Expert Mode or ensuring the default value aren’t being set in the database
- If the Change Indicator attribute is using a different type than the one in the database, the compare will fail. (I had the issue with Oracle.jbo.domain.Timestamp VS java.sql.Timestamp)
- Ensure they have the same type
- In last recourse: set the Change Indicator value in your View Object or Entity Object to one specific attribute.
You can read more about this here :
- https://community.oracle.com/blogs/amaan_junaid/2015/12/05/adf-another-user-have-changed-the-row-with-primary-key-oraclejborowinconsistentexception-jbo-25014
- https://blogs.oracle.com/onesizedoesntfitall/the-case-of-the-phantom-adf-developer-and-other-yarns
- http://www.rponte.com.br/2017/09/11/adf-jbo-25014-another-user-has-changed-the-row-with-primary-key/