openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Albert Lee" <allee8...@gmail.com>
Subject Re: [jira] Created: (OPENJPA-126) EntityManagers cannot be serialized
Date Thu, 08 Feb 2007 23:44:09 GMT
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) <jira@apache.org> 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.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message