Hi Craig,
Craig L Russell wrote:
> 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.
This won't work if the entity's serialization contract skips or modifies
any persistent attributes: merge assumes that the instance to be merged
is newer than the one in the persistence context and will override the
corresponding values:
3.2.4.1 Merging Detached Entity State
"If X is a detached entity, the state of X is copied onto a pre-existing managed
entity instance X'"....
thanks,
-marina
>
> 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!
>
>