JDeveloper Frequently Asked Questions: FAQ #14 - How to test an Application Module for activation-safe in ADF 11g

Introduction

For ADF applications, Activation refers to the process of re-instating an Application Module (AM) from a stored snapshot. A recommended test practice for ADF applications is to ensure that AMs are tested for activation-safe. This FAQ will show you how to do so.

Main Theme

The intricacies of Application Module state management are quite complex and if we were to describe it in a brief paragraph and as simple as possible we would say:

"For each request, as AMs are allocated from a pre-defined pool, they become associated with specific sessions, acquire a transactional state and become referenced by specific Data Controls (DC). The AMs along with their acquired state are returned back to the pool as soon as the request is serviced. When all AMs in the pool are used, i.e. all of them have a state and are associated with specific sessions and DCs, it becomes necessary to store the state of one such AM to the database (Passivation) and then assign it to some other session. Activation is the reverse process of restoring the state of a previously passivated AM. Once it is activated, the AM has its transactional state restored and becomes re-referenced by its original session and DC."

Testing an AM for activation-safe ensures that the transactional state of the AM being activated is intact up to the moment when it was actually passivated. In order to do such a test, we need to force the AM to go through a passivation/activation cycle. We can accomplish this by disabling AM pooling. This is easily done by right-clicking on the application module in the Application Navigator and selecting Configurations... to bring up the Manage Configurations dialog.

Select the Local configuration and click Edit... to bring up the Edit Business Components Configuration dialog. Click on the Pooling and Scalability tab and deselect the Enable Application Module Pooling option.

Disabling Application Module pooling has the effect of setting the jbo.ampool.doampooling configuration property to false as it is shown below.

Because there is no AM pool in use, this in effect turns on the passivation/activation cycle forcing a Passivation to occur at the end of each request as the AM is de-referenced from the session and the DC. Activation takes place on the next request when the AM along with its transactional state is reconstructed from the passivation store - usually a database - and is re-referenced to the session and the DC in order to service the request. Once you setup debug logging in the console, the activation/passivation cycle becomes obvious by examining the log messages in the Log console. Observe what is happening as you do uncommitted changes to your view objects. Passivation XML records are generated for each request describing the data changes - the data before and after the changes. These records are written to the PS_TXN table of the passivation store.

The passivation store defaults to the database used by the AM database but it can be specified to a different database by setting the property jbo.server.internal_connection in AM configuration as it is shown below.

The passivation store can also be a file in the system file by setting the AM configuration property jbo.passivationstore as it is shown below. The file system location can be specified by setting the property jbo.tmpdir.