Serialization of PersistenceManagers

[Craig L Russell <Cr...@Sun.COM>]

This is one of the last items before we release JDO 2.1.

We need to specify the behavior of a persistence manager if it  
implements Serializable and its writeObject method is called.  
Subsequently, the stream is materialized in a different context and  
the persistence manager is created from the stream. What are the  
conditions that would allow the persistence manager to reactivate  
itself from the restored state?

Use case: In an ejb container, a persistence manager is a persistent  
property of a Stateful Session Bean. The bean is serialized for  
storage. The bean might then be passivated and removed from the  
container. At some future time, and perhaps in some different VM, the  
bean might be activated, and the persistence manager along with all  
the other state is restored. Subsequently, an invocation on the bean  
occurs and a business method calls a method on the persistence manager.

Use case: In a web application, a persistence manager is a value of a  
session attribute. The session state is serialized and stored.  At  
some future time, and perhaps in some different VM, the session might  
be activated, and the persistence manager along with all the other  
state is restored. Subsequently, a request is serviced by the session  
and a business method calls a method on the persistence manager.

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: Serialization of PersistenceManagers

[Craig L Russell <Cr...@Sun.COM>]

Hi Erik,

Thanks for your comments.

On Oct 29, 2007, at 12:01 PM, Erik Bengtson wrote:

>> This is one of the last items before we release JDO 2.1.
>
>> We need to specify the behavior of a persistence manager if it
>> implements Serializable and its writeObject method is called.
>
> Couple of questions.
>
> Portability:
> Do we look after portability on serialization? I mean, can PM of
> implementation A be serialized and deserialized using  
> implementation B?

I would not mandate this. I think it's hard enough to reconnect a PM  
to its PMF when deserialized. I don't think having a portable  
serialization format is required.
>
> Transaction:
> Can we serialize while there is an ongoing pessimistic transaction?

I'd say no. The state of the transaction cannot be reproduced reliably.

> Can we serialize while there is an ongoing optimistic transaction?

Good question. Since we cannot reliably reproduce the datastore  
transaction state when deserializing it, we either have to mandate  
that you cannot serialize after enlisting a datastore transaction  
(e.g. after flush()) or just say you cannot serialize if a  
transaction is active. I'd rather be conservative for our first try  
and disallow serialization if any transaction is active.

> Do we suspend the transaction on serialize and resume on deserialize?

I don't see the jdo implementation being responsible for suspending  
or resuming transactions.
>
> NonTransactionWrite:
> What happens if the PC objects are not serializable?

The non-serializable instances are not reachable from serializable  
instances, although serializable instances are reachable from non- 
serializable instances.

I'd propose that we treat non-serializable instances by serializing  
the persistent state and letting the listeners and callbacks handle  
the non-persistent state. The other reasonable option is to throw an  
exception.
>
> Listeners:
> What about the listeners?

This is part of the state that can't be completely replicated when  
deserialized. We could require that the listeners be serializable as  
well (putting the onus on the listener code), and that the classes  
that are registered are restored using the corresponding classes in  
the deserialized environment.

> if user classes are not defined in the other JVM, do we allow partial
> deserialization?

I'd have to call that an error.
>
> Environment configuration:
> I imagine that we have to serialize the PMF too, so if a connection  
> defined
> at PMF has username and password, should they be serialized too?

This is one of the trickiest issues: restoring the association with a  
PMF. I think we have to look at how the PMF was configured originally  
and replay some of the initialization of the PMF. For example, using  
the JNDI name of the PMF could be portable. Using the name of the PMF  
and in the new environment replaying JDOHelper.getPMF(String name) to  
find the PMF might be portable. I do think that the configuration in  
the deserialized environment might not be identical to the  
configuration in the serialize environment. Such basic things as the  
data source name or connection parameters might be different. So  
getting the environment right would be the biggest issue.

Craig
>
> Regards,
>
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

RE: Serialization of PersistenceManagers

[Erik Bengtson <er...@jpox.org>]

>This is one of the last items before we release JDO 2.1.

>We need to specify the behavior of a persistence manager if it  
>implements Serializable and its writeObject method is called.  

Couple of questions.

Portability:
Do we look after portability on serialization? I mean, can PM of
implementation A be serialized and deserialized using implementation B?

Transaction:
Can we serialize while there is an ongoing pessimistic transaction?
Can we serialize while there is an ongoing optimistic transaction?
Do we suspend the transaction on serialize and resume on deserialize?

NonTransactionWrite:
What happens if the PC objects are not serializable?

Listeners:
What about the listeners?
if user classes are not defined in the other JVM, do we allow partial
deserialization?

Environment configuration:
I imagine that we have to serialize the PMF too, so if a connection defined
at PMF has username and password, should they be serialized too?

Regards,