Wednesday, February 1, 2012

Ensuring that your ADF Application is Passivation/Activation Safe

Hi everyone,

Just a quick note on passivation/activation. ADF works with two pools, Application (via AMs) and Database (via your database connection). Each time a user accesses a resource and that resource uses an AM to display data, the Application Module pool manager assigns an AM instance to the user session. If the pool runs out of connections, the AM pool Manager passivates the state of one of the sessions (either in the database or in a file), thus releasing an instance and assigning it to the new session. When the user that was passivated resumes their work, ADF will activate their state from the configured store. This is done automatically for you for all attributes that are mapped to a database column.

However, for transient attributes and transient views, if you do not mark them to be passivated, their state will be lost, and during activation will be empty. You can test if your ADF application is passivation/activation safe by deselecting the “Enable Application Module Pooling” option in the “Pooling and Scalability” tab of the AM configurations. This will basically force the framework to passivate/activate your session state with every click that you perform.

***NOTE*** Do not forget to enable AM pooling once you have tested your application.

To mark a transient attribute that is part of a normal view to be passivated, you just need to select the “Passivate” attribute on a the view object attribute.



In the case of a transient view (programmatic) though, you need to do a couple of things:

a) Mark the whole view, including all transient attributes to be passivated
b) Make sure that the “No Rows” option is selected in the “Retrieve from the Database” section is selected
c) Override the beforeRollback and afterRollback methods in the ViewObjImpl class by commenting out the call to super.

1 comment:

  1. Thanks Antonis. This clears up a few things.

    ReplyDelete