Is Your Application PASSIVATION SAFE???

PASSIVATION for Business Objects (ADFbc)

Overview
Application state :
State of the application specifies the context a particular session. Technically for Business objects (ADFbc), it denotes the pending changes to the database.

Passivation :
Freezing the application state data on to the database of a particular user session.

Activation :
Reading back the application state data from the database of the particular user session.

Application Module pool :
In order to improve availability of Managed business objects (ie application module), a single Application Module is always instantiated to a specified number of instances and kept in container which is called 'Application Module Pool'. (since object creation (in java) is considered to be highest performance hit, Application modules are instantiated already (before any request from user) and kept in the pool and also for object re-use). When the user session request for a page in the middle tier, the page's corresponding application Module instance is take from the application module pool and assigned to the session.

Why Passivation/Activation is required?
Consider the follow scenario, Page 'P' requires Application Module 'A' to display data or for any DML(insert/update/delete) operations. Lets say Application Module Pool count is 5 (which means we have 5 Application Module 'A' instances in the pool). suppose, when the user 'U1' requests for the Page 'P', Application module pool Manager assigns one Application Module 'A' instance to the user session 'U1'(from the pool). At the same time, when 'User U2' requests for Page 'P',Application module pool Manager assigns 2nd Application Module 'A' instance to the user session 'U2. so for users U3, U4, U5...When the user 'U6' requests for Page 'P', then Application module pool Manager freeze (passivate) any of the application module 'A' instance (say which is used for User 'U2') to the database and resets that Application Module instance and assigns to User 'U6'. Now again when the user 'u2' reqests for Page 'P' or commit the pending changes , the appplication Module pool manager freeze (passivate) any of other application module 'A' instance, and reads the state (acitvate) for the user 'U2' from the database and loads the Application Module A instance with the data and assigns to User 'U2'.

Why Developers needs to make sure application is passivation safe?
At the very look, it might look passivation and activation is supposed to be job of the framework. To a good extent, Yes. But not 100%. Developer also need to co-operate with the framework to make sure that application is passivation safe. So it is important for the developer to understand 'Application state management' behavior of the ADFbc.

Activation/Passivation behavior of View Objects:
Framework does not store view object's data (ie. all rows attribute values) during passivation. It only stores view object query(and its bind variable values) to the DB. During activation, Framework re-executes the query(with its bind variables) and populates view object attributes.

Role of Developers
Transient view attributes in VO's based on EO's:
Since Transient view attributes are not mapped to Sql column, developer needs to take care of populating the values. Below are the 2 cases,
1.Transient view object attribute which are derived from other normal view object attribute(s)(through getter method of Transient view object's attribute)
Developer dont have to take care of this case.
2.Other Transient view object attribute(s):
Developer needs to explicitly ask the framework to passivate transient view attributes.
In the attributes section, Edit the particular attribute, enable 'passivate' checkbox.

Transient view object:
Since Transient view object deprived of sql query, Developer needs to follow the steps during creation of Transient VO to facilitate proper passivation/activation:
1) Set the VO option: Rows populated programmatically, not based on a query
2) On the General page, expand the Tuning section and select Passivate State. Also select the
Including All Transient Attributes option
3) In the Tuning section, for the Retrieve from Database group box, select the No Rows option.
4) In the VOImpl override the following methods: beforeRollback() and afterRollback(). In these
overridden methods comment out the call to Super.
5) Make sure you have set one of the VO attributes as the "Key Attribute" else the passivation will fail.

 Instance variables in AMImpl class, VOImpl class, VORowImpl Class, EOImpl class:
Instances variables are not passivated by the framework. Framework recommends not to use any instance variables by the developer. If at all developer badly needs instance variables in any of the Impl class, Developer needs to explicitly override 'passivateState' and 'activateState' methods(in corresponding Impl) to passivate and activate those variables.