Last updated: 29/3/2011
How it works?
Application Pooling
Due to the natural "think time" inherent in the end user's interaction with your application user interface, the number of application module instances in the pool can be smaller than the overall number of active users using the system. For this reason, ADF applications provide the application module pooling feature. 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.
As shown below, as a given end user visits multiple pages in your application to accomplish a logical task, with each page request an application module instance in the pool is acquired automatically from the pool for the lifetime of that one request. At the end of the request, the instance is automatically returned to the pool for use by another user session. In order to protect the end user's work against application server failure, the application module supports the ability to freeze the set of pending changes in its entity caches to a persistent store by saving an XML snapshot describing the change set. For scalability reasons, this state snapshot is typically saved in a state management schema that is a different database schema than the one containing the application data.
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.
More on BC Passivation in related posts.
Part of this post is from excellent Chris Muir post and Simon Lessard Forum comment. Thanx.
Sample/Test case
Find sample/test case in Andrejus excellent post Demystifying ADF BC Passivation and Activation!
Dig:
No comments:
Post a Comment