openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey (JIRA)" <>
Subject [jira] Updated: (OPENJPA-126) EntityManagers cannot be serialized
Date Tue, 20 Nov 2007 19:43:43 GMT


Patrick Linskey updated OPENJPA-126:

    Attachment: openjpa-126.patch

This patch implements this feature as far as I am aware, including serialization of in-memory
savepoints. It works for both enhanced and unenhanced persistent types.

Primary limitations:

- the entity classes in the entity manager must be Serializable

- cannot serialize a pessimistic transaction

- cannot serialize a broker that has been flushed

- cannot serialize a broker that has affinity to a particular connection

I have not done any testing in a managed environment whatsoever.

I plan to commit these changes after making a jar available to some people for initial acceptance
testing in the wild.

> EntityManagers cannot be serialized
> -----------------------------------
>                 Key: OPENJPA-126
>                 URL:
>             Project: OpenJPA
>          Issue Type: New Feature
>          Components: jpa, kernel
>            Reporter: Patrick Linskey
>             Fix For: 1.1.0
>         Attachments: openjpa-126.patch
> 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.

View raw message