At its most simple, an application module pool is a collection of instances of a single application module type which are shared by MULTIPLE application clients. For example, the ADF Toy Store application has an application module named toystore.model.services.ToyStoreService. An application module pool supporting the Toy Store demo would have one or more instances of this application module COMPONENT in it, based on the number of users that are visiting the site.

This pool of AM instances is shared by multiple browser clients whose typical "think time" between submitting web pages allows optimizing the number of AM components to be EFFECTIVELY smaller than the total number of "ACTIVE" users working on the system. That is, twenty users shopping the web site from their browser might be able to be serviced by 5 or 10 application module instances instead of having as many AM instances as you have browser users.

Application module components can be used to support web application scenarios that are completely stateless, or they can be used to support a unit of work which spans multiple browser pages.

At any one moment in time, the instances of application modules in the pool are logically partitioned into three groups, reflecting their state:

Unconditionally available for use Available for use, but referenced for session affinity reuse by an active USER session XYZ Unavailable, inasmuch as it's currently in use (at that very moment!) by some thread in the web container.

At its most simple, an application module pool is a collection of instances of a single application module type which are shared by multiple application clients. For example, the ADF Toy Store application has an application module named toystore.model.services.ToyStoreService. An application module pool supporting the Toy Store demo would have one or more instances of this application module component in it, based on the number of users that are visiting the site.

This pool of AM instances is shared by multiple browser clients whose typical "think time" between submitting web pages allows optimizing the number of AM components to be effectively smaller than the total number of "active" users working on the system. That is, twenty users shopping the web site from their browser might be able to be serviced by 5 or 10 application module instances instead of having as many AM instances as you have browser users.

Application module components can be used to support web application scenarios that are completely stateless, or they can be used to support a unit of work which spans multiple browser pages.

At any one moment in time, the instances of application modules in the pool are logically partitioned into three groups, reflecting their state:

Unconditionally available for use Available for use, but referenced for session affinity reuse by an active user session XYZ Unavailable, inasmuch as it's currently in use (at that very moment!) by some thread in the web container.