The name that Oracle gave to the level of its ADF framework where the business logic is done is called the Application Module. It is from within this application module (and the view objects that it contains) that the database transactions and business decisions are controlled. Though the details of how ADF connects everything between the HttpSession and Application Modules are unnecessary for the purposes of these next few paragraphs, know that ADF essentially assigns an Application Module to the HttpSession when it is requested (for example, from an action class). However, it is not possible for ADF to have an infinite instances of each application module available for each user. Each user (read: HttpSession) will use only one instance of each application module that it needs (a unique identifer for this instance is kept in the SessionCookie). At the end of each HttpRequest, the application module is checked back into the 'pool'.
There are three 'state management' features for application modules. Unmanaged (stateless), managed (stateful), and reserved (also stateful). Obviously an unmanaged application module will be checked in, and no state will be kept once the HttpRequest is over. In managed and reserved levels, state is kept. The difference between the two is that in reserved level, the HttpSession will always receive the same instance of the application module. In managed level, ADF will do it's best to keep a single application module associated with the HttpSession. However; if there are only 10 application modules in the pool and 11 users request it, it must do something to keep the state of one application module so that it can be cleared out and given to user #11.
In this situation, ADF 'passivates' the state of the application module. All row sets, row indicators, new rows, new data, changes made to view objects, and their queries, and other such data is stored by ADF in an XML format. This way, a user can receive a different instance of an application module, but still have all of the changes that were made to it. There was an awful lot of background information leading up to this point, but there is one thing that ADF does not passivate that can be quite important, depending on how it is used. Any transient information - or any data not backed by entity objects, is not passivated by default. So it is very important that if you have any transient information that needs to be passivated, be sure to check the box in the view object configuration. It is important to note that transient information is slightly more 'expensive' in terms of performance to passivate (as opposed to entity-backed information which is typically saved at the entity object level).
A great (and far more detailed) article that covers the information above and more can be found here.
