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] Updated: (JDO-455) Write test cases for serialization behavior of PersistenceManager
Date Fri, 29 Feb 2008 23:53:51 GMT

     [ 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
> 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.

View raw message