From: Craig L Russell <Craig.Russell_at_Sun.COM>
Date: Tue, 18 Jul 2006 14:37:44 -0700

On Jul 18, 2006, at 2:28 PM, Kenneth Saks wrote:

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

You can say the same about UserTransaction. I'd say that
TransactionSynchronizationRegistry would be a good thing to add to
the spec in maintenance. The point of listing the objects that are
handled automatically is to avoid every user doing the same thing,
since the container knows exactly what needs to be done.
>
>
> 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.

Good point. I agree.

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

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!