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/j
do/CurrentDevelopment

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

The scenario we are looking at is where a front end web client accesses a we
b server via standard http/html protocol/data requests. Multiple interaction
s 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 mig
ht have the effect of changing state on the session, and these changes becom
e part of the session state
. While some of this state is transient, and used to update the back end dat
abase only upon specific request, other state represents persistent data (e.
g. backing beans for forms). Changes to these backing beans must be maintain
ed 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 bea
ns and using optimistic locking protocols on the PersistenceManager. But the
re 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 newl
y acquired PersistenceManager. When the request leaves, the beans are detach
ed and maintained as sessio
n state. This pattern works well but there is a lot of infrastructure requir
ed in order to implement it. In particular, it is difficult to identify the 
list of persistent instances that must be detached and attached. The behavio
r of the beans depends on t
he environment.

A somewhat easier pattern for the user to implement is the "PersistenceManag
er Per Session" pattern. With this pattern, a new PersistenceManager is acqu
ired 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 ind
ependent parts: a) the state of the PersistenceManager itself, b) the state 
of the associated PersistenceManagerFactory, and c) the states of the user-v
isible persistent instances

[ Post a follow-up to this message ]