关于Oracle adf 报Thread: JBO-25014: Another user has changed the row with primary key oracle.jbo.Key

PS:本文我又补了个译文

网上的解决方案:

The oracle.jbo.RowInconsistentException is the BC4J framework's way of telling you that another user has changed the row since your current user initially queried it. This is an important feature to avoid against the so-called "Lost Update Problem" if two users try to modify the same row in sequence. Depending on whether you are using pessimistic or optimistic locking, you may see the error as soon as you attempt to modify any attribute of an entity object with pessimistic locking or you may see it during the post/commit processing for optimistic locking. Our locking mode defaults to pessimistic, and can be set globally by providing a value like optimistic for the jbo.locking.mode configuration property in the configuration for the application module that you use as the root application module for your application.

You can use the BC4J tester (by picking the "Test..." option from the right-mouse menu on your application module) to simulate the situation in which this error will occur. Just launch two separate testers by selecting "Test..." twice. With two instances of the BC4J tester running, query up the same row in both and then make a modification to some attribute in that row using one of the tester windows, followed by commit. When you try in the 2nd tester window to modify an attribute in that same row, you'll get the oracle.jbo.RowInconsistentException raised -- immediately if you leave the default pessimistic locking mode, or at commit time with jbo.locking.mode=optimistic in your configuration.


If your BC4J/ADF-based application is getting the this exception, then one of two things is going on:


Another user really has updated the row since your current user retrieved it
Your application may contain a problem that makes BC4J think that the row has been changed when logically no other user has really changed it.
After understanding how we detect that the row has changed, we'll look at a couple of reasons this error might occur unintentionally.


When we go to lock a row for update, against Oracle we issue a SQL statement like this:


SELECT <list of all columns to which your entity object's persistent attributes are mapped>
  FROM <table name that your entity object is mapped to>
 WHERE <primary key columns = current values of corresponding PK attributes of entity>
  FOR UPDATE NOWAIT
If we succeed in locking the row, the we have in our hot little hands the values of all the persistent attributes in your entity object instance that we just selected during the lock attempt. These represent the most current state of the committed database values for the attributes.


If you do not have any attribute marked as a "Change Indicator" attribute -- in which case we would only compare the value of that single change indicator attribute -- then we compare the just-selected-during-the-lock values with the values of attributes that we have in the entity object as they existed at the time you selected them originally. These "original values" are the same values that are available to you as the Entity Object developer using the getPostedAttribute() API. If any of the just-selected-during-the-lock attribute values differs from the original values of the current entity object instance, the RowInconsistentException is thrown.


Five common reasons for which this error can be thrown when logically you believe it should not, are:


You have database triggers modifying the values of some of  the columns on which your entity's persistent attributes are based, and you have failed to correctly indicate that to BC4J with the "Refresh on Insert" and/or "Refresh on Update" flags on the entity object attribute definition.
You have (or have added) database level column default values for attributes and failed to correctly indicate that to BC4J with the "Refresh on Insert" property for the corresponding attribute.
You have created a view object with "Expert Mode" custom SQL statement, and have gotten the SELECT list of your custom SQL statement out of sync with the view object attributes.
You are using an attribute whose type is a custom domain class and have failed to correctly implement the equals() method for your custom domain class. 
Your are using a ROWID-valued attribute in your entity and have not marked it to "Refresh on Insert" and "Refresh on Update". Some features of the database like partitioning can cause the value of ROWID to be updated when data in the row is updated.
In the first and second cases, set the refresh flags appropriately for any related entity object attributes that your triggers are changing.


In the third case, double-check that your custom SQL statement is not accidentally selecting the value of the wrong column inadvertently into your view object attributes, and visit the "Attribute Mappings" panel to verify that the select-list to view object attribute mappings are as they should be.


In the fourth case, BC4J relies on your domain class'  being able to compare itself properly with another instance of the same class, so you'll need to implement a correctly-functioning equals() method for your custom domain class.


In the fifth case, just mark the indicated attribute flags to avoid the problem.