Here's an updated proposal, including feedback received from the
original message.
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.
If an Entity is referenced via a Serializable field of the Session
Bean (either directly or via the Serializable closure of a Session
Bean field), then that Entity is detached via the standard
Serialization contract (see Persistence 3.2.4 Detached Entities: A
detached entity may result from ... serializing an entity). The
Entity can be merged into the Session Bean's new persistence context
by explicitly adding a merge operation to the PostActivate callback.
Non-persistent fields in Entities in the persistence context are not
stored by the EM, as they are not part of the persistence contract.
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 can assume
that the Session Bean's application environment is active in the VM
into which the Session Bean is activated.
The EM is responsible for restoring the state of the persistence
context in any VM 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 new
persistence context. The contents of non-persistent fields is not
specified after activation in the new 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 "Core Contracts 4.2 A container
must not passivate a stateful session bean with an extended
persistence context unless the following conditions are met:• 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