db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Russell (JIRA)" <j...@apache.org>
Subject [jira] Created: (JDO-455) Specify serialization behavior of PersistenceManager
Date Fri, 22 Dec 2006 22:26:21 GMT
Specify serialization behavior of PersistenceManager

                 Key: JDO-455
                 URL: http://issues.apache.org/jira/browse/JDO-455
             Project: JDO
          Issue Type: New Feature
          Components: specification, tck2, tck2-legacy
    Affects Versions: JDO 2 final
            Reporter: Craig Russell
             Fix For: JDO 2 maintenance release 1

This is item 15 in the JDO 2.1 approved changes list. See http://wiki.apache.org/jdo/CurrentDevelopment

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.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message