In a previous blog post I highlighted the issue of ADF Prematurely Terminating Task Flows
, essentially where ADF page fragment based task flows embedded in regions can be terminated early by their enclosing page causing some interesting side effects. In that post I concluded the behavior was restricted to task flows embedded in regions, and to be honest besides a log out/timeout scenario, I thought this issue could only occur in regions.
While reading our documentation on the CLIENT_STATE_MAX_TOKENS
and browser back button support I realized there is indeed another prematurely terminating task flow scenario for page based task flows rather than fragment based task flows which we'll describe here. For anyone who hasn't read the previous blog post
, I suggest you read it before reading this post as it won't make much sense otherwise.
Let's describe the application we'll use to demonstrate the scenario:
1) First it contains an unbounded task flow which includes a ViewCountries.jspx page to show data from the Countries table, followed by call to a countries-task-flow.xml.
2) The ViewCounteries.jspx page contains a read-only af:table showing countries data and the ability to select a record, an edit button to navigate to the countries-task-flow, and finally a plain old submit button.
4) The countries-task-flow includes an EditCountries.jspx and an exit Task Flow Return Commit activity.
Note the countries-task-flow transaction options are set to Always Begin New Transaction and a shared Data Control Scope:
6) Finally the EditCountries.jspx page includes an editable af:form for the countries data, and a button to exit the task flow via the Task Flow Return Commit activity.
Similar to the last blog post we'll use ADFLoggers
on the underlying Application Module to show what's happening under the hood.
On running the application and accessing the ViewCountries.jspx page
we see the Application Module initialized in the logs:
<AppModuleImpl> <create> AppModuleImpl created as ROOT AM
<AppModuleImpl> <prepareSession> AppModuleImpl prepareSession() called as ROOT AM
We'll pick the Brazil record....
....then the edit button which navigates us to the EditCountries.jspx page within the countries-task-flow. Note the Brazil record is showing as the current row as the countries-task-flow is using a shared data control scope:
Now if we use the browser back button to return to the previous page we see something interesting in the logs as soon as we click the button.....
<AppModuleImpl> <beforeRollback> AppModuleImpl beforeRollback() called as ROOT AM
....and because of the rollback note that the current row has reset to the first row:
As promised this is another prematurely terminating task flow scenario, this time with pages rather than fragments. As we can see the framework on detecting the back button press terminates the task flow's transaction by automatically issuing the rollback.
You can download the sample application from here.