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 2008/05/27 03:06:00 UTC

[jira] Resolved: (OPENJPA-126) EntityManagers cannot be serialized

     [ https://issues.apache.org/jira/browse/OPENJPA-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patrick Linskey resolved OPENJPA-126.
-------------------------------------

    Resolution: Fixed

> EntityManagers cannot be serialized
> -----------------------------------
>
>                 Key: OPENJPA-126
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-126
>             Project: OpenJPA
>          Issue Type: New Feature
>          Components: jpa, kernel
>    Affects Versions: 1.1.0
>            Reporter: Patrick Linskey
>            Priority: Blocker
>             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.