Patrick,
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.
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.
EJB Container supporting JPA must honor this condition. 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.
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?
Any insight is greatly appreciated
Thanks
Albert Lee
On 2/7/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:
EntityManagers cannot be serialized
-----------------------------------
Key: OPENJPA-126
URL: https://issues.apache.org/jira/browse/OPENJPA-126
Project: OpenJPA
Issue Type: New Feature
Components: kernel, jpa
Reporter: Patrick Linskey
EntityManagers are not serializable or externalizable. This makes
passivation of an EntityManager a difficult task. We should investigate how
to externalize an EntityManager in a meaningful way. This could mean just
writing out a stub that contains configuration information (potentially even
just the persistence unit name, or the Configuration's ID), or it could mean
actually serializing some or all of the local transactional cache to disk.
The implications for the functionality available after deserialization would
differ depending on the approach taken.
I would like to see an implementation that efficiently wrote all the
unflushed, dirty objects to disk. This would probably be best implemented
via a writeReplace() strategy, to avoid handling all the transient fields in
a Broker. Deserialization would then turn into a factory lookup plus some
sort of in-place reattachment of the deserialized unflushed instances.
Of course, if the entity instances themselves were not serializable, it
would be difficult to write them to disk. Theoretically, we could just write
out the corresponding StateManagers, and track the changed fields ourselves.
I do not think that this is a good approach, however, since it would cause
the deserialized objects to lose any non-persistent state after
deserialization. I think that it is fair to require that instances be
declared Serializable in order to use this feature.
(We could optimize this a tad by detecting if an instance has only
persistent fields, and if so, do our own serialization work.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
