ADF Application Session Failover, a Myth or Reality
18786Apr 23 2008 — edited Feb 13 2009Create a simple application (mimicking balance inquiry) consisting of two pages
The first page is a simple search form that displays the names of a few bank customers, the second page is a details page that shows customer balance
A navigation button exists in the first page to link you to the details (balance) page.
No coding is really needed.
Follow the following customer experience
1- The bank teller searches for a customer (Joh%)
2- 4 records meet the search criteria
3- The teller selects the 3rd row
4- The teller navigates to balances page
5- The teller sees that customer's balance
So far so good everybody is happy
Another Scenario
1- The bank teller searches for a customer (Joh%)
2- 4 Records meet the search Criteria
3- The teller selects the 3rd row
4- The teller gets engaged with a phone call
5- The session times out
6- the Teller navigates to the balances page
7- the teller thinks that he/she sees the customer balance
8- The teller makes a wrong decision because what the teller really sees is the balance of the first row in the interator (Row one in previous page). The teller goes home happy not knowing that he could have caused a disaster
No Warning, No complain,???
Is this acceptable ?!
You will have to tell the bank management the following
"Extracted from Jdeveloper Developer Guide http://www.oracle.com/webapps/online-help/jdeveloper/10.1.3/state/content/navId.4/navSetId._/vtAnchor.CHDDEEDH/vtTopicFile.bcadfdevguide%7Cbcstatemgmt~htm/Do "
I am here only showing the relative stuff
" When the HttpSession times out the BindingContext goes out of scope, and along with it, any data controls that might have referenced application modules released to the pool in the managed state level. The application module pool resets any of these referenced application modules and marks the instances unreferenced again."
That explains it and explain that the iterator shall be executed again since it has no reference in the pool. It explains it, but does it justify it?
Ok, But ADF comes to your rescue, with another extract from the same article
"Passivation Snapshot Retained in Failover Mode
When the failover mode is enabled, if the HttpSession times out due to session inactivity, then the passivation snapshot is retained so that the end user can continue their work when they return to their browser.
After a break in the action, when the end user returns to his browser and continues to use the application, it continues working as if nothing had changed. In failover mode, the ADF runtime saves an additional browser cookie that the ADF runtime uses to track the latest passivation snapshot ID for each client running an application in failover mode. So, even though the users next request will be processed in the context of a new HttpSession (perhaps even in a different application server instance), the user is unaware that this has occurred. The additional browser cookie is used to reactivate any available application module instance with the user's last pending state snapshot before handling the request."
You call the bank and tell them to rest assured that such situation shall never happen again.
you go to your OC4J 10.1.3 and add the following Java parameter
-Djbo.dofailover=true
-Djbo.debugoutput=console
restart the application server
change the timeout setting in web.xml to 1 minute for testing
repeat the steps above
still the app module is not retained and there was no session failover, even though the console showed passivation occurring at each request!
I doubled checked that i allow cookies etc ...
Of course this scenario is not the actual one,, the application is much more complex than this. And there is no security login screen.
The two issues are:
1) is it really reasonable to accept the fact that when the session times out, the framework is so forgiving
2) is there an issue with the Failover implementation ?
Sorry for this long post
Ammar Sajdi
Amman Jordan