What is the fail over feature provided by the Application Module?

The fail over feature decides when and how often passivation happens. When this feature is turned on, the application module state is turned on everytime an application module instance is returned back to the AM pool by the data control.

The advantage of this feature is that the user application state (model state), remains intact.

When should this feature be enabled/used?
This feature should be enabled only in the applications where its absolutely critical not to lose the data entered by the users at any cost.
Mostly it should be enabled, when we are dealing with a clustered environment.

When should we keep away from using this feature?
When this feature is enabled, passivation/activation happens for every request. This brings down the performance of the system . So in applications where its not critical to lose data, do no enable this feature. Especially when we are not dealing with a clustered environment then do not enable this feature.

How to enable/disable it?
This feature can be enabled or disabled by selection appropriate properties in the application module configuration on the Pooling and Scalability tab of the Business Components Configuration dialog.

 What is the default configuration?
This feature is disabled by default.

In many cases there are requirements, where every user session needs a seperate object to be used throughout the session.
For example, let us take the example where there is requirement to access the SOA related data from the Application Module. To access the data from the SOA server, a connection has to be established to the SOA server and then appropriate data has to be queried. The same connection cannot be used by all users (or cannot be used in all user sessions). Every user session should have a seperate connection, so that when queries are executed, only the data related to the user are fetched. So for every user session, a seperate connection object is required.

So how can we make evey user have a seperate unserializable object?

The simplest way to achieve this is to re-create the object every time it is required. But in many cases, recreating such objects can have serious performance implications. So what else can be done?

The only other thing that can be done is to minimize the number of times the object is re-created.
This can be achieved by storing the non-serializable objects in the session of the DB transaction associated to the Application module.

The following piece of code shows how to do that..

getDBTransaction().getSession().getUserData().put("key",non_serializable_obj_instance);

So the overall procedure should be as follows..

• Check whether the require object is present in the user session
• If the object is present , just it
• If the object is not present, create an instance of the object. Put a reference of the object in the session and use the reference.

The session associated to the transaction, gets re-initialized whenever passivation/activation happens. So all the objects placed in the session will be gone after the passivation/activation cycle.

Basically, every user request will be given an AM instance from the AM pool. Before the response for the user request is sent back to the client, the AM instance will be saved back to the AM pool. A user may not be given the AM instance which was given to him previously. This can happen, when all the free AM instances have been used up . Before giving an AM instance to a user, ADFbc checks if the AM instance has been serving the previous requests of the user. If not, the framework will passivate all the AM state and will re-intialize its state so that it can start serving the new user.

During this entire process, there are few hook points in the Application Module class where the developer can have custom logic to implement his requirements. The most important of these hook points is the method "prepareSession(Session sessionParam)".

This method will be called, in the following cases.

• When there are free AM instances, and a user has sent a request for the first time.
• When all the free AM instances are used up and one on the AM instances has to serve the request of a new user.