persistence@glassfish.java.net

Re: Passivating an EM

From: Kenneth Saks <Kenneth.Saks_at_Sun.COM>
Date: Tue, 18 Jul 2006 17:28:05 -0400

Craig L Russell wrote:

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

UserTransaction and Resource Manager connection factories are both
required to be handled by the container via Section 4.2.1 of EJB Core
Contracts. I haven't see any mention of the serialization behavior of
TransactionSynchronizationRegistry in the specs. anyone else? It
should easy enough to just reacquire it within readObject().


One additional requirement is that the EM must be capable of restoring
its state in either the same JVM or in a different JVM than the one in
which writeObject() was called. The EM can assume that the application
to which it belongs is already running when readObject() is called.
  

>
> 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!
>
>