adfemg
  1. adfemg
  2. ADFEMG-79

BTF doesn't honor restore to save point on first run

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Labels:
      None

      Description

      Logged this issue and the relating bug 16009286 for Leon so he can track it without having to lodge an SR. The issue isn't critical to his business, just an anomaly he's detected.

      <-bug text->

      I've logged this issue against controller-transaction
      component-subscomponents, but could equally go against ADF BC, it's hard to
      me to guess where the fault lies.

      A customer has discovered a scenario where Bounded Task Flow (BTF) with Task
      Flow Return activity "Restore Save Point" set is ignored with multiple root
      AMs, but only on the first run, appears the save points work in all
      subsequent runs.

      Characteristics of app:

      1) Application based on Oracle HR schema
      2) Two separate root ADF BC Application Modules (AMs), one exposing
      DepartmentsView, the other EmployeesView
      3) Three task flows called in a chain, UTF to view & select departments,
      BTF#1 to edit the 1st DepartmentsView row, BTF#2 to edit the 1st
      EmployeesView row
      4) Task flow options:

      4.1) BTF#1 EditDepartmentsTaskFlow - Always Begin New Transaction + Shared
      data control scope + Commit & Return Task Flow Return activities
      4.2) BTF#2 EditEmployeesTaskFlow - Always Use Existing Transaction + Shared
      data control scope + "None" Task Flow Return activity + "Restore Save Point"
      Task Flow Return activity

      No other default settings have been changed to build this application.

      To reproduce the issue follow these steps:

      1) Unzip uploaded simple test case SavePointTaskFlowTransactionsSplitAM.zip
      2) Open the unzipped application in JDeveloper
      3) Change the configuration of the database connection to point to an Oracle
      HR demo schema you can access
      4) Run the ViewDepartments.jsf page in the adfc-config.xml

      5) In the running app ViewDepartments.jsf page select any record and select
      the edit button
      6) On arriving in BTF#1 change the current department's name
      7) Select the Edit Employees button
      8) On arriving in BTF#2 change the current employee's name
      9) Select the RollbackSavepoint button
      10) On returning to BTF#1 select Commit

      11) Via the database navigator in JDev, note that both the departments and
      employees record have been updated with your changes. The employees record
      should not have been as step #9 was rolling back to the savepoint established
      with BTF#2 was called. The savepoint is created because on BTF#2 the No Save
      Point on Task Flow Entry check box is not set (implying the savepoint was
      created).

      12) Now repeat steps to 5 to 11. Note that once you inspect the changes in
      the database for every subsequent run of steps 5 to 11, the departments
      record will be changed, but the employees record will not. This is the
      expected behaviour.

      As such to explicitly state the problem, the savepoint is dishonoured the 1st
      time through the above scenario, but every subsequent time it is followed.

      As follow up to this bug I've also uploaded a separate test case
      SavePointTaskFlowTransactionsOneAM.zip, which doesn't use two root AMs. If
      you repeat the previous steps you wont see the issue described above. As
      such at face value the problem appears to be related to how ADFc and the dual
      root AMs are interacting.

      <-end bug text->

        Activity

          People

          • Assignee:
            Unassigned
            Reporter:
            chriscmuir
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: