From: Craig L Russell <Craig.Russell_at_Sun.COM>
Date: Tue, 18 Jul 2006 12:05:53 -0700

Hi Marina,

On Jul 18, 2006, at 11:52 AM, Marina Vatkina wrote:

> Hi Craig,
>
> Thanks for writing this up. I have a question though: why do you
> have this
> (strong - "must not") requirement no to use entity serialization
> for EM
> serialization?

The reason is that it interferes with the EM's requirements to
capture the "persistent state" of the Entity. There is no requirement
that the user's writeObject include all of the persistent state of
the Entity, so the EM cannot rely on all of the state being written.
[A persistent field might not be serialized, but it must be written
by the EM.]

The other reason is that if an Entity happens to be a field directly
referenced by a SSB or servlet, that Entity will be serialized by the
container, and if the EM also serializes it, the serialization
mechanism would make the restored instances identical. Then, when the
EM restores the persistent field state, it would have the effect of
modifying the field that was serialized as a direct field, violating
the serialization contract.

There is already a strong contract in place between the EM and the
Entity for accessing the persistent state of the Entity. This
mechanism must be used when the EM serializes the persistence context
or you will hopelessly confuse the different contracts (persistent
state and serialization).

Craig
>
> thanks,
> -marina
>
> 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).
>> 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!