[ADFEMG-79] BTF doesn't honor restore to save point on first run Created: 17/Dec/12 Updated: 05/Sep/13 Resolved: 05/Sep/13
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
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
A customer has discovered a scenario where Bounded Task Flow (BTF) with Task
Characteristics of app:
1) Application based on Oracle HR schema
4.1) BTF#1 EditDepartmentsTaskFlow - Always Begin New Transaction + Shared
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
5) In the running app ViewDepartments.jsf page select any record and select
11) Via the database navigator in JDev, note that both the departments and
12) Now repeat steps to 5 to 11. Note that once you inspect the changes in
As such to explicitly state the problem, the savepoint is dishonoured the 1st
As follow up to this bug I've also uploaded a separate test case
|Comment by Jan Vervecken [ 18/Dec/12 ]|
On My Oracle Support I have been able to find 16009286, "BTF DOESN'T HONOR RESTORE TO SAVE POINT ON FIRST RUN", which currently has "Product Version 22.214.171.124.0".
If I run some VersionFinder code  on the files in SavePointTaskFlowTransactionsSplitAM.zip and SavePointTaskFlowTransactionsOneAM.zip (attached to this JIRA issue
Can someone please point out which JDeveloper version should be used on the contents of SavePointTaskFlowTransactionsSplitAM.zip and SavePointTaskFlowTransactionsOneAM.zip ?
|Comment by chriscmuir [ 20/Dec/12 ]|
Well spotted, logged against the wrong version. Corrected the bug to 126.96.36.199.0, though the issue can also be reproduced in 188.8.131.52.0.
|Comment by Jan Vervecken [ 28/Dec/12 ]|
Thank you for the update Chris.
Also wanted to confirm that I have been able to reproduce the behaviour you describe, using SavePointTaskFlowTransactionsSplitAM.zip and SavePointTaskFlowTransactionsOneAM.zip and JDeveloper 184.108.40.206.0 .
|Comment by Jan Vervecken [ 05/Jan/13 ]|
There seem to be functional differences between the application in "SavePointTaskFlowTransactionsOneAM.zip" (which uses a child View Object instance that allows to edit the first employee for a department) and "SavePointTaskFlowTransactionsSplitAM.zip" (which has no such child View Object instance (also because of the separate Application Modules) only allowing to edit the first employee, unrelated to a department), so a functional difference.
|Comment by Jan Vervecken [ 05/Jan/13 ]|
Did you notice that two separate database session/connection SID values are involved for a single request, for the scenario you describe using SavePointTaskFlowTransactionsSplitAM.zip ?
To illustrate this I added some logging (using a MyApplicationModuleListener ) resulting in the example application
Notice the different SID values "(am502) SID = 48" and "(am501) SID = 40" for different Application Module instances during request [r1007].
If on the task-flow "EditDepartmentsTaskFlow" the Transaction option "Share data controls with calling task flow" is changed from checked to unchecked (so from "shared" to "isolated") the same request no longer reports two separate database session/connection SID values used, only one for both Application Module instances.
(Yes, this also changes the functional behaviour of the application (no longer allowing to edit the selected department), but it is just to illustrate the difference.)
Notice the same SID values "(am503) SID = 17" and "(am502) SID = 17" for different Application Module instances during request [r1007].
(Also notice that, instead of one, now two Application Module instances are created in the ApplicationPool "model.AppModuleLocal", "(ap21)[cre 2 ... tot am 2 ..." compared to "(ap21)[cre 1 .. tot am 1 ..." before, as can be expected after the data-control-scope isolated change.)
|Comment by chriscmuir [ 06/Jan/13 ]|
Good spot on SavePointTaskFlowTransactionsOneAM.zip Jan. I've retested with the EmployeesView3 as a parent VO under the AM to get the same expected behaviour. I can't upload the updated zip here until the Java.net file attachment issue is resolved, but I'll upload it to the bug.
On your other observations, (and btw, your logging software once again proves very useful to show the internal behaviour, well done), I think it explains an important part about the task flow transaction options and that is about where the AMs are instantiated.
As you likely already know (but as a recap for other readers), specifically using a combination of ADF BC and the task flow transaction options (that is, Always Begin New Transaction, Always Use Existing Transaction, Use Existing Transaction if Possible, but*not <No Controller Transaction>), root AM connections will be shared. If you wish to use root AM's that definitely have separate data sources (connections), look to using the <No Controller Transaction> option instead.
One thing to keep in mind is the UTF has no transaction settings but is the equivalent of using <No Controller Transaction>.
Returning to your observations with all this logic in hand, we would expect the connections of the two separate AMs to be shared (or in other words, just 1 connection).
But there is something else important to note & it will change the behaviour, and that is when/where the AMs are instantiated.
As the DeptAppModule is first instantiated in the UTF, it is in fact running under the <No Controller Transaction> regime. This will influence it's behaviour right through the other BTFs. As such even though the EmpAppModule is instantiated under a BTF transaction option that wants to share connections with other root AMs, the DeptAppModule wont play ball as when it was instantiated the UTF said it shouldn't participate in the task flow transaction regime with other AMs.
(Hopefully that language makes sense, I'm still thinking about how to articulate this clearly and simply)
Now when you switch over to the isolated data control scope, as the DeptAppModule is instantiated twice, once in the UTF, and once separately in the first BTF, that second BTF DeptAppModule is a BTF that's working under the task flow transaction options that want to share connections and it will join/share connections with the EmpAppModule that is also running under the same task flow transaction regime.
So I believe this explains the different connection behaviour you've discovered.
As you've observed, with the joined connection behaviour it seems to get the rollback behaviour right. And in my mind this should be very functionally similar to SavePointTaskFlowTransactionsOneAM.zip. However I still don't get the original bug observed. Given that it works the 2nd iteration I feel as if there is code in there to deal with this scenario, but somehow the first iteration it's not working.
We have observed in other tests that there is in another connection taken out with the database, it's something internal to the framework, but just once and it has something to do with the savepoint mechanism too. I was hoping this bug logged with the dev team will give us a chance to understand what's happening under the covers.
This description has all been written up on the weekend and hasn't had my full attention, let me know is there is anything that isn't clear.
|Comment by chriscmuir [ 17/May/13 ]|
Dev team have notified that the issue isn't reproducible in 12.1.2, but is in 220.127.116.11.0. They continue to investigate.
|Comment by chriscmuir [ 05/Sep/13 ]|
This has been fixed in an internal release 18.104.22.168.1.
As this is no longer reproducible/is fixed in the 22.214.171.124.0 release there is no further work to pursue on this issue. Will close issue.