Hi Marina,
On Aug 8, 2006, at 2:34 PM, Marina Vatkina wrote:
> 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:
It's not clear to me what the problem is. How is this different from
the "normal" case of detachment by serialization? If the user's
serialization behavior doesn't work in this case, under what
circumstances will it ever work?
An example might help clarify your issue for me.
Thanks,
Craig
> 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!
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