Passivation and Activation in Oracle ADF—jbo.passivationstore

The passivation/activation implementation in Oracle ADF Business Components^[1] is designed to keep transaction states across multiple requests or sessions.

In this article, we will discuss one aspect of the passivation/activation implementation in Oracle Fusion Applications—the passivation store.

Passivation and Activation

There are two kinds of pools in use when running a typical Fusion web application:

• Application Module (AM) pools
• Database connection pools

An application module pool is a collection of instances of a single application module type which are shared by multiple application clients. As for database connection pools, they are usually maintained by the J2EE container. You can read [9] for more details. To tune Fusion Application's performance, you need to understand both pools^[8].

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.

Passivation Store

In order to manage application module pending work, the application module pool asks AM instances to "snapshot" their state to XML at different times. If the value of the jbo.dofailover configuration parameter is true (default), then this XML snapshotting will happen each time the AM instance is released to the pool.

The AM instance snapshots can be saved either in the database or in a file. To configure it, you can set jbo.passivationstore to be:

• database
• file

File Store

If you set jbo.passivationstore to be file, by default passivation should go to use.dir. However, you can change the location by setting:

• -Djbo.tmpdir

For example, in our CRM Fusion Application, we have selected file to be the passivation store. But, we didn't set its location (i..e jbo.tmpdir). By default, it used "user.dir":

• <Installation Home>/instance/domains/<Server Name>/CRMDomain

To find out where "user.dir" points to on Linux, you can do:

$ls -l /proc/<pid>/cwd
cwd -> /c1/mt/rup1/instance/domains/myserver/CRMDomain

So, going to that directory, you can find a bunch of files used by CRM for passivation:

-rw-r----- 1 mygrp testuser 6380   Oct 11 10:04 BCacc13d9BCD
-rw-r----- 1 mygrp testuser 263    Oct 11 10:04 BC325e092dBCD
-rw-r----- 1 mygrp testuser 127186 Oct 11 10:04 BC166a7e7fBCD


DB Store

If you set jbo.passivationstore to be database (default), XML snapshots will be written to a BLOB column in a row of the PS_TXN table in the database.

While the file-based option is a little faster, unless your multiple application server instances share a file system, then the the database-backed passivation scheme is the most robust for application server-farm and failover scenarios.

Configuration Parameters

To summarize, the following configuration parameters are related to this topic:

• jbo.dofailover
• Enables eager passivation or not
• jbo.passivationstore
• Dictates the store type
• jbo.tmpdir
• Specifies the location for file store

You can reference [10] for other application module pool configuration parameters.

References

1. Oracle ADF Essentials
2. Reusable ADF Components—Application Modules
3. Java System Properties
4. Why is the user.dir system property working in Java?
5. ADF BC Passivation/Activation and SQL Execution Tuning
6. Demystifying ADF BC Passivation and Activation
7. Ensuring that your ADF Application is Passivation/Activation Safe
8. Understanding Application Module Pooling Concepts and Configuration Parameters
9. Monitoring WebLogic JDBC Connection Pool at Runtime
10. What You May Need to Know About Application Module Pool Parameters