I triaged a bug report today where a customer was surprised at the behavior of their view object when they performed the following sequence of steps:
- Set their application module configuration properties to run in "Failover Mode"
- Programmatically called setWhereClause() to add a where clause that took one bind variable and called setWhereClauseParam() to set the bind variable value, and executed the query to display the results in a web page.
- Programmatically called setWhereClause() to change the where clause of the same view object instance to one that took two bind variables, and called setWhereClauseParam() twice to set each of those two bind variables, and executed the query to display the results in a web page.
- While keeping their browser window open, shutdown their application server to simulate a failure of the application server.
- They then started the application server again, and clicked on a link in that still-opened window to cause the "where clause with one bind variables" code described above to execute again. This was so observe that the application could "keep going" after an application server failure.
Only trouble was, their code had apparently never been tested in the conditions when the application module actually did undergo failover reactivation, or they would have observed this behavior during the testing phase. The ADF Business Components failover feature guarantees that your view object instances are reactivated (in the new application server instance) using the same user-defined where clause, bind variables and bind variable values that they had the last time they were executed. So, in the above sequence, the last time they were executed before failing-over, the VO had had two bind variables at VO execution time, and the next time they were used, the code was assuming only one was now needed.
An easy way to eagerly excercise the application failover feature during testing is to visit the Application Module configuration editor's "Pooling and Scalability" page and uncheck the Application Pooling Enabled checkbox. When you run with that configuration property unchecked, it will force the application module's state to be reactivated on each HTTP request so that you can verify that your code will work the same way when application module reactivating occurs at runtime.
AM reactivation from "dehydrated" a pending state snapshot can occur both during an application failover scenario, as well as under extreme load when the value of your jbo.recyclethreshold is not large enough to allow all simultaneous users to enjoy the better performance of "sticking" with the same application module instance from the AM pool that they "touched" on their last HTTP "visit" to the middle-tier.
So, the moral of the story is that it's always good to test your application with application module pooling disabled just to make sure you won't have any surprises in your production environment should your client end up working with an application module instance that has been reactivated from saved state.
10:56:56 PM 
|
|
