You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Patrick Linskey (JIRA)" <ji...@apache.org> on 2007/02/07 18:26:05 UTC
[jira] Created: (OPENJPA-126) EntityManagers cannot be serialized
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.
RE: [jira] Created: (OPENJPA-126) EntityManagers cannot be serialized
Posted by Patrick Linskey <pl...@bea.com>.
> 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.
Re: [jira] Created: (OPENJPA-126) EntityManagers cannot be serialized
Posted by Albert Lee <al...@gmail.com>.
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) <ji...@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.
>
>