Description

In Chapter 12, specify the behavior of PersistenceManager if it extends Serializable and writeObject is called.

The scenario we are looking at is where a front end web client accesses a web server via standard http/html protocol/data requests. Multiple interactions compose a database transaction. Additionally, new Javascript/AJAX patterns might allow the web page to send multiple concurrent requests to the same back end session, which must maintain state across these multiple requests. Some of the interactions might have the effect of changing state on the session, and these changes become part of the session state. While some of this state is transient, and used to update the back end database only upon specific request, other state represents persistent data (e.g. backing beans for forms). Changes to these backing beans must be maintained across requests and flushed to the database only upon specific behavior typically initiated from the front end client.

Changes made to persistent backing beans present the possibility of database conflicts, which can be managed by implementing version checking on the beans and using optimistic locking protocols on the PersistenceManager. But there are cases where the session state must be serialized.

Using a "PersistenceManager per request" pattern, a list of backing beans is maintained and when the request arrives, the beans are attached to the newly acquired PersistenceManager. When the request leaves, the beans are detached and maintained as session state. This pattern works well but there is a lot of infrastructure required in order to implement it. In particular, it is difficult to identify the list of persistent instances that must be detached and attached. The behavior of the beans depends on the environment.

A somewhat easier pattern for the user to implement is the "PersistenceManager Per Session" pattern. With this pattern, a new PersistenceManager is acquired by the user for a session, which might span multiple requests. There is no need to keep track explicitly of persistent instances, because they are not required to be detached as long as the same PersistenceManager is used. This is the pattern we will focus on for the serializable PersistenceManager behavior.

The state of the PersistenceManager's context consists of three somewhat independent parts: a) the state of the PersistenceManager itself, b) the state of the associated PersistenceManagerFactory, and c) the states of the user-visible persistent instances.

For a), we can assume state such as the Optimistic and NontransactionalRead flags can be serialized in some proprietary way. For b), the configuration of the PersistenceManagerFactory for use in the web or application server might only need a jndi name, and the properties used to reconstruct the factory upon deserialization can be implementation-specific. But c) presents challenges.

It is clear that the PersistenceManager has enough information to serialize the persistent instances in the cache, including the before-image information and the changed and loaded field information. But what is not clear is what the interaction should be between the instances and their own serialization contract. Specifically, if there are some persistent instances in the stored session state, these instances will be serialized along with the session itself according to the serialization contract of the session and the persistent classes.

It seems that the interaction between the PersistenceManager and the serialization contracts of the session and persistent classes is the major issue for the specification.