8.8 Supporting Multipage Units of Work

During the span of time your end user is interacting with your application, she might:

• Visit the same pages multiple times, expecting fast response times

• Perform a logical unit of work that requires visiting many different pages to complete

• Need to perform a partial "rollback" of a pending set of changes they've made but haven't saved yet.

• Unwittingly be the victim of an application server failure in a server farm before saving pending changes

This section provides a brief overview of the application module pooling and state management features that simplify implementing scalable, well-performing applications that address these requirements.

8.8.1 Overview of Application Module Pooling and State Management

Applications you build that leverage an application module as their business service take advantage of an automatic 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. 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.

As shown in Figure 8-13, as a given end user visits multiple pages in your application to accomplish her logical task, on 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 "dehydrate" 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.

Figure 8-13 Using Pooled Application Modules Throughout a Multipage, Logical Unit of Work

The pooling algorithm affords a tunable optimization whereby a certain number of application module instances will attempt to stay "sticky" to the last user session that returned them to the pool. The optimization is not an iron-clad guarantee, but when a user can benefit by the optimization they continue to work with the same application module instance from the pool as long as system load allows. When load is too high, the pooling algorithm uses any available instance in the pool to service the user's request and the dehydrated "snapshot" of their logical unit of work is rehydrated from the persistent store to allow the new instance of the application module to continue where the last one left off. The end user continues to work in this way until they commit or rollback their changes.

Using these facilities, the application module delivers the productivity of a stateful development paradigm that can easily handle multi-page work flows, in an architecture that delivers the runtime performance near that of a completely stateless application. You will learn more about these application module features in Chapter 28, "Application Module State Management" and about how to tune them in Chapter 29, "Understanding Application Module Pooling".

Note: This application module pooling and state management is also available for thin-client, desktop-fidelity Swing applications and web-style user interfaces.

8.8.2 Experimenting with State Management in the Business Components Browser

For a quick taste of what the state management functionality does, you can launch the Business Components Browser on the devguide.model.SRService application module and try the following steps:

1. Double-click on the OpenProblemsAndAssignees view object instance to query its data.

2. Make a note of the current values of the Status and the Assigned To attributes for a few rows.

3. Update those rows to have a different value for Status and Assigned To, but do not commit the changes.

4. Choose File | Save Transaction State from the Business Components Browser main menu.

   A Passivated Transaction State dialog appears, indicating a numerical transaction ID number. Make a note of this number.

   Exit the Business Components Browser and then restart it.

5. Exit out of the Business Components Browser completely.

6. Restart the Business Components Browser and double-click on the OpenProblemsAndAssignees view object instance to query its data.

7. Notice that the data is not changed. The queried data from the data reflects the current state of the database without your changes.

8. Choose File | Restore Transaction State from the Business Components Browser main menu, and enter the transaction ID you noted in step 4.

At this point you'll see that your pending change set is reflected again in the rows you modified. If you commit the transaction now, your changes are permanently saved to the database.