Managing Application State
HTTP is a stateless protocol. ADF model supports both stateless applications as well as those involving a unit of work that may span multiple pages.
An application module supports passivating its pending transaction state to an XML document, which is stored in the database in a single, generic table, keyed by a unique passivation snapshot ID. It also supports the reverse operation of activating pending transaction state from one of these saved XML “snapshots.”
You can demonstrate passivation in the Business Component Browser by making changes without saving them and then selecting File > Save Transaction State. A dialog box displays the transaction key ID. Then close and reopen the BC Browser; it displays the original data without your changes. Select File > Restore Transaction State to restore the pending changes, which you can then commit to the database if desired.
Passivation and activation are performed automatically in an ADF BC application by the application module pool, which is discussed in the next slide. This automatic state management provides the simplicity of a stateful programming model that is nearly as scalable as a completely stateless application.