1 Reply Latest reply: Mar 26, 2013 8:52 AM by Jan Vervecken RSS

    lost update detection with 'modified on' History Column

    Jan Vervecken
      hi

      Please consider the workaround suggested by Steve Muench, "161.Signal RowInconsistentException Correctly Across Activation/Passivation [11.1.1.6] 12-MAR-2013 " [1], using a Change Indicator attribute marked as a 'version number' History Column.

      The documentation section "4.10.11 How to Protect Against Losing Simultaneously Updated Data " [2] says:
      "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. ... Alternatively, you can indicate that the entity object should manage updating the change-indicator attribute's value using the history attribute feature ... "

      So, trying to implement the suggested workaround using a Change Indicator attribute marked as a 'modified on' History Column resulted in the example application created using JDeveloper 11.1.1.6.0
      at http://www.consideringred.com/files/oracle/2013/Bug14689126NoRowInconsistentExceptionApp-v0.02.zip

      Note that it has "-Djbo.ampool.doampooling=false" configured. [3]
      Note that its Employees.HireDate Entity Object attribute is a Change Indicator attribute marked as a 'modified on' History Column.
      Note that tryEmployeesVO.jspx includes a tr:inputHidden component for this Change Indicator attribute value.

      But, still scenario (sc1) behaves the same as before [4] :
      - (sc1-a) run the view "tryEmployeesVO" in JDeveloper, and open a second browser session
      - (sc1-b) in both browser sessions navigate to the same record (e.g. with "Email NKOCHHAR")
      - (sc1-c) in the first browser session change the value of the Email attribute (e.g. to "NKOCHHA1"), and click the Commit button, the change should be applied in the database
      - (sc1-d) in the second browser session also change the value of the Email attribute (e.g. to "NKOCHHA2"), and click the Commit button, the change is applied in the database without an error message

      How can this alternative implementation of the suggested workaround be improved for proper lost update detection?

      - [1] https://blogs.oracle.com/smuenchadf/resource/examples#161
      (see also forum thread "Signal Row Modified By Another User Exception Even When AMPooling Disabled"
      at Signal Row Modified By Another User Exception Even When AMPooling Disabled )
      - [2] http://docs.oracle.com/cd/E23943_01/web.1111/b31974/bcentities.htm#ADFFD200
      - [3] see documentation section "40.10.2 Disabling Application Module Pooling to Test Activation"
      at http://docs.oracle.com/cd/E23943_01/web.1111/b31974/bcstatemgmt.htm#ADFFD1328
      - [4] http://java.net/jira/browse/ADFEMG-62
      and http://www.consideringred.com/files/oracle/2012/Bug14689126NoRowInconsistentExceptionApp-v0.01.zip

      many thanks
      Jan Vervecken
        • 1. Re: lost update detection with 'modified on' History Column
          Jan Vervecken
          fyi

          In the context of SR 3-6322025251 I got this feedback:
          'The way I found to make it work is to change the Employees.HireDate Entity Object attribute format to Format Type "Simple Date" "and Format "yyyy-MM-dd G 'at' hh:mm:ss" '

          This resulted in a modified example application
          at http://www.consideringred.com/files/oracle/2013/Bug14689126NoRowInconsistentExceptionApp-v0.03.zip
          which seems to improve the behaviour in scenario (sc1) for lost update detection.

          (see also a related issue in ADFEMG JIRA issue ADFEMG-119, "ViewAttribute IsUpdateable added when View Row class generated",
          at http://java.net/jira/browse/ADFEMG-119 )

          regards
          Jan