| Craig Russell (JIRA) 2006-12-22, 7:11 pm |
| 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 t
o 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 flus
hed 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 sess
ion 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 sessio
n 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 t
he 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 expl
icitly 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
|