Hi,
Here is a straw proposal for specifying the contract between the
container and the EM for passivation:
The EM must be Serializable [Core contracts 4.2], and the container
invokes the EM writeObject (ObjectOutputStream) during passivation.
The EM writes the current persistence context to the output stream,
including the current state of managed fields and properties of
managed Entities.
During activation (either in the same VM or in a different VM) the EM
is read via readObject (java.io.ObjectInputStream). The stream has
the contents that were written during writeObject.
The EM is responsible for restoring the state of the persistence
context as of the time of passivation. Specifically, the restored
persistence context contains exactly each Entity that was managed by
the saved persistence context. The state of each persistent property
or field in each Entity is restored to the persistence context.
The EM relies on the container to properly serialize and deserialize
references to UserTransaction, TransactionSynchronizationRegistry,
and ResourceFactories (specifically including JDBC DataSource).
The EM must not use the user-defined serialization behavior of Entity
classes, as this behavior is in the domain of the POJO and is not
part of the persistence infrastructure. Specifically, writeObject,
writeExternal, writeReplace, readObject, readExternal, readResolve
methods of Entity classes must not be invoked by the EM during the
process.
The restriction in the specification "4.2 A container must not
passivate a stateful session bean with an extended persistence
context unless the following conditions are met:[9] • All the
entities in the persistence context are serializable. " is ignored.
Craig
Craig Russell
Architect, Sun Java Enterprise System
http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell_at_sun.com
P.S. A good JDO? O, Gasp!
- application/pkcs7-signature attachment: smime.p7s