> How do you see this feature be used? The only > "realistic/official" usage I > can see is during stateful session bean passivation in the > EJB container.
Agreed; this will probably cover the majority of use cases. I imagine people would potentially use the feature with just straight HTTP sessions, too. > However there are also wording on the condition passivation > can apply. E.g. > In ejb-3_0-fr-spec-ejbcore.pdf Section 4.2. > > - A container may only passivate a stateful session bean > instance when the > instance is not in a transaction. > - 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. > * The EntityManager is serializable. > > The first condition already eliminates the need for > application-managed and > transaction-scoped persistence context to be passivated since the > persistence context outside of a transaction should be empty. > > The second condition implies in extended-scoped persistence > context, if > EntityManager is NOT serializable or any entity is NOT > serializable, SFSB > passivation is not allowed. An implementation provider could certainly decide that it wants to go beyond what is allowed in the spec. Personally, I think that these spec rules are a bit limiting in many scenarios. There's no reason why OpenJPA needs to constrain itself to the limitations of the Java EE specifications. > EJB Container supporting JPA must honor this condition. Well, not really.... an implementation need not honor any conditions aside from those, and, to the extent that there is a CTS test in place to assert the negative, the default configuration must fail in the user-limiting way. > Since most container > implementation injects entity manager proxy to component > instances, the > provider's entity manager will be de-coupled from the SFSB passivation > scenario. i.e. the persistence context may not need to be > passivated. I can > imagine it is a good feature to implement provider entity > manager and/or > persistence context passivation for the same reason as the SFSB > passiviation, the JPA architecture has no definition how this > should be > surfaced to the provider client. Agreed, but making the EntityManager serializable is the "right" way to implement this feature in my opinion. The EntityManager knows the most about what needs to be serialized; it is therefore the most efficient place to do the work. IOW, if we were to make the OpenJPAEntityManager serializable, then the container could trivially passivate the SFSBs using that EntityManager. > From container perspective, how one can determine the "All > the entities in > the persistence context are serializable." condition under > the current JPA > spec so that the second condition can be implemented in the container? Oh, that's pretty easy -- try to serialize, and fail lazily when a NotSerializableException is thrown. Or, during the serialization operation, do an instanceof on all the user objects before serialization. -Patrick _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
