An application module pool is a collection of application module instances of the same type, such as an Orders application module or a Human Resources application module. This pool of application module instances is shared by multiple browser clients. The amount of time between submitting Web pages enables a smaller number of application module components to serve a larger number of active users. This reduces memory usage and improves performance.
This facility manages a configurable set of application module instances that grows and shrinks as the end-user load on your application changes during the day.
At any one time, the pool may contain application module instances that are partitioned into
three groups, based on their state. When the processing of a current HTTP request completes, the application module instance is checked back into the pool. If the AM instance has managed state, the pool keeps track that the AM is referenced by that particular session.
For example –
We have pool of 5 Application module instances. After having request from multiple browser , request will go to instance, which is available for time being.We have 3 state defined for appModule instances –
1- Available
2- Partially available- but referenced for preferred reuses by an another active session that would be more efficient due to the managed state of the application module.
3- Unavailable- because it is being used at that very moment by a Web container thread
You can configure application module pool behavior, sizing, and cleanup behavior. For more information about this, refer to the Fusion Developer’s Guide for ADF in online Help.
Note: Pools are created only for root application modules, not for nested ones that users access indirectly through a root application module.
In short –
Application module pooling:
• Enables users to share application modules
• Manages application state
• Provides the same instance or one with an identical state
when requested by an application with managed state
State management –
The PS_TXN and PS_TXN_SEQ are used by ADF to serialize user session state to the database (the state management schema).PS_TXN will only get created when/if an application module needs to be passivated. If your application module pool is big enough, it’s possible that you won’t see it get created.
Happy Learning with Vinay Kumar in techartifact…