Hi Craig,
There is a scenario that I am not able to handle using the proposal. It
is described below:
SFSB *s1* has an extended PC *em1* and a reference to a managed entity
*e1*. s1 *also* uses another local SFSB (say) *s2*. s2 holds a reference
to e1 as part of its state, but s2 does *not* use an entity manager.
Since s1 and s2 are in same VM, all changes made by s2 on e1 are still
being tracked by em1. So, there are two reference to the managed entity
e1 from two different SFSBs although one of the SFSBs is not using
entity manager explicitly. In pseudo code, this is how it looks like:
@Stateful public class S1 implements I_S1 {
@PersistenceContext(type=EXTENDED) EntityManager em1;
Employee e1;
@EJB I_S2 s2;
@PostActivate public void ejbActivate(){
e1 = em1.merge(e1);
}
// business method used for initialization of the SFSB
public void initialize(String empId) {
e1 = em1.find(Employee.class, empId);
s2.initialize(e1);
}
}
@Stateful public class S2 implements I_S2 {
Employee e1;
// business method used for initialization of the SFSB
public void initialize(Employee e1) {
this.e1 = e1;
}
... // other business methods
}
When s1 is passivated and reactivated, s1 and s2 will refer to two
different entities, won't they?
Ken,
In this case, when s1 is passivated, is s2 also passivated?
If yes, does s2 get reactivated as soon as s1 is activated?
What would have happened there were no persistence context here and
Employee were just a Serializable class? After activation, would s1 and
s2 refer to same Employee object?
Thanks,
Sahoo
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.
>
> 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!
>
>