The One-PM-per-Session Design

In the one-pm-per-session design, when the controller receives a request, it begins by looking in the HttpSession object for a handle to the service. If it does not find one, it creates a handle to the service and stores it in the session. The handle is used to wrap the service so that the service can be closed when the session is serialized or invalidated. The handle reacts to session invalidation or serialization in the callbacks defined by the HttpSessionBindingListener interface and the HttpSessionActivationListener interface defined in the javax.servlet.http package.

Like the one-pm-per-request design, this design can benefit greatly from the level-two cache of a sophisticated JDO implementation. Unlike the one-pm-per-request design, this design can supply some caching benefit when a level-two cache is not present. By turning on the NontransactionalRead, Optimistic, and RetainValues properties in the transaction, the application can cause the persistence manager to accumulate persistent state across requests from the same client. At the same time, the issue of managing cache size or age is not serious because the persistence manager is serving only one client for the duration of his visit. If the user needs to refresh the entire cache from time to time, a button to request this action can be provided.

The one-pm-per-session design may generate less garbage during a client's visit to the Web site than the one-pm-per-request design—but only if the dynamic pages reuse a lot of the same persistent objects. Otherwise, the amount of garbage is about the same.

The one-pm-per-session design appears to shine when considering transactions. If transactions are used, then a JDO transaction is available to tie the request that generates the view to the request that performs the update. As a result, there is no reason for the application to define a versioning scheme.

Close examination reveals, however, that this design gains little in performance while either introducing complexity or jeopardizing scalability. Unless the JDO implementation does not provide a level-two cache, this design's increased use of the persistence manager's cache offers little advantage. At the same time, the reduction in garbage generation may not be significant.

As described earlier, the persistence manager cannot be serialized and should be closed when the session is serialized. Although session serialization can be avoided by configuring the servlet container to turn it off, to do so jeopardizes load handling and clustering. Any failure to scale is a serious flaw in most Web applications. To support session serialization, the application detects when session serialization occurs and closes the persistence manager on these occasions. If the persistence manager may be closed between requests, then any advantages hoped for by keeping the persistence manager open may or may not be present when a request is processed. To maintain scalability, the code must be able to handle the request even when the persistence manager has closed. For much work, little is gained over the one-pm-per-request design.

In short, the one-pm-per-session design gains little in performance, potentially loses in scalability, and complicates the design and the code. For these reasons, it cannot be recommended over the one-pm-per-request design.