What is Application Module Pool and how it works??

Application Module is the transaction controller of the ADF Application.

1. Any database related activity of Business Components in ADF Application is performed through the Application Module. 
2. Changes made by the Application Module can be Committed and Rollback at any instance of the transaction. 
3. Application Module can perform a series of database changes in a single session. 
4. Each Application Module creates a single database connection.

Application Module pooling is done by WebLogic to reuse the free Application Module Instances. This helps in making the Application Scalable.

That means though Application Module pooling, the application can handle transactions even if the no. of users session is greater than the no. of database connections.

The Application Module instance can be shared between users or browser clients. This helps in maintaining low memory usage and improves the performance of the Application.

When the Application Module is shared then the current transaction is saved in the PS_TXN table in the database. And after that, the Application Module instance is available for other uses.

Application Module Pooling works through Passivation and Activation.

Passivation: This is the process in which the state of an Application Module is saved in Database tables in serialized form.

Activation: This is the process in which the Application Module state is reviewed from the database tables.

Let's take an example of a User creating Sales Order and SalesOrderAM is the application Module that is being used.

1. User login in the system to make some kind of transaction.e.g. to book Sales Order.
2. When the request comes then Weblogic will check for free Application Module Instance.
3. If there is no free instance in the application Module pool, then a new Application Module Instance will be created and allocated to the transaction.
4. If there is a free instance then that instance will be allocated to that transaction.
5. The user continues with the transaction and then when the user session is idle and some other request comes up and there is no free instance.
6. In this case, the current Application Module state will saved in the database in PS_TXN tables. And the Application Module instance will be made available for the new request. This is called Passivation.
7. When the second user completes its transaction and the first user resumes, in this case, the Application Module state will be reviewed from the saved state in the database. This is called Activation.
8. Application Module instance increases until the max pool size. Max Pool Size is the maximum no. of Application Modules that can be created.

There may be cases where you will not see any entry in PS_TXN tables, this is possible if the Application Module pool size is large enough and Application Module instance sharing is not required.