[
https://issues.apache.org/jira/browse/JDO-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig Russell updated JDO-455:
------------------------------
Component/s: (was: specification)
Fix Version/s: (was: JDO 2 maintenance release 1)
Summary: Write test cases for serialization behavior of
PersistenceManager (was: Specify serialization behavior of PersistenceManager)
The specification has been updated. Now we need to write test cases for the
tck.
> Write test cases for serialization behavior of PersistenceManager
> -----------------------------------------------------------------
>
> Key: JDO-455
> URL: https://issues.apache.org/jira/browse/JDO-455
> Project: JDO
> Issue Type: New Feature
> Components: tck2, tck2-legacy
> Affects Versions: JDO 2 final
> Reporter: Craig Russell
>
> 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.
-
You can reply to this email to add a comment to the issue online.
