High Available (HA) checklist for ADF applications

Making ADF application HA enabled, there are two groups of actions that should be performed. One is the configuration and the second is the development part of work. Below you'll find my checklist:

1. in adf-config.xml descriptor put code <adf-scope-ha-support>true</adf-scope-ha-support>
   
   
2. in weblogic.xml descriptor set session persistent store type as REPLICATED_IF_CLUSTERED
   
   
3. each application module must have jbo.dofailover attribute set to true
   
   
4. if you're using POJO DataControls, you need to implement three methods there: createSnapshot(), restoreSnapshot(Serializable handle) and removeSnapshot(Serializable handle); more about that here: Creating and Configuring Bean Data Controls
5. each bean defined in the memory scope higher than request level must implement java.io.Serializable interface
• avoid using java transient keyword regarding to the bean attributes
• each attribute that extends UIComponent aren't serializable! if UI component must be binded with the code, use org.apache.myfaces.trinidad.util.ComponentReference wrapper there
• make the framework aware of changes that needs to be replicated against the cluster, mark the scope as dirty, ie. using ControllerContext.getInstance().markScopeDirty(AdfFacesContext.getCurrentInstance().getViewScope());
6. each page flow and session attributes must implement java.io.Serializable interface

 As short as possible. Hope it'll be helpful :)

what is page definition scope? how many instances of the data controls will be created at runtime?

Asking question about pageFlowScope, sessionScope and others leads to one of the most important (in my opinion) graphs:

source:http://docs.oracle.com/cd/E24382_01/web.1112/e16181/img/lc_scope.png

What is worth to mention, applicationScope lives with an application within the JVM container. If you have clustered environment, you'll have at most one instance per node (lazy init principle).

Nevertheless, what is page definition scope or data control scope? How many instances of data controlls will be created in runtime? Quote from the docs:

"(...) the binding container, the binding objects it contains, and the values the binding objects reference are defined in session scope."

But it doesn't mean that there is equation one session == one binding container (data control instance). Please notice that ADF introduces taskflows and task flow transactions. If your application uses a lot of task flows as regions on one page and some of them are always creating new transactions (on the controller level), per each session you'll have more than one binding frame.

As a summary - from the time point of view, each data control instance (each binding container) will live as long as user session exist. From the instances count point of view, per each session you'll have 0..n instances of the data controls (depends on total number of used task flows on your pages, task flow transaction setting and the page definition contents).

state machines validation using Groove expressions

Very often there is a business requirement that defines some kind of a state machine. Each business entity has its own lifecycle, it can be created, published, modified, archived and so on. Transitions between states are usually one way. If a bank transfer is complete it cannot be rolled back to the prepared state. In other words, it means that validation depends on new and old value of the same attribute.

Recently I've worked on such requirement and the validation have been implemented as valueChangeListener on af:selectOneChoice. There is simplier solution and development must be done in model layer. Reasonable because valueChangeListener is assigned to one instance of the attribute usage in the project. And such attribute may be used in various pages. And there is no guarantee that developers there know about such validation.

Because new value depends on the previous, it fits to other patterns as well. Employees in a company can have their salary attribute to be updated. But who wants to have the new salary lower than current? :) Nobody I think.

Please open entity Employees, select Salary attribute and specify new script validation rule:

Print command is just to log the new value in the JDev console. Further, specify the error message and run the example page:

Which is the most important here - Groove allows to refer to new and old values by using newValue and oldValue keywords.