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.
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
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
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
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
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->