db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Serialization of PersistenceManagers
Date Tue, 30 Oct 2007 17:30:04 GMT
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  
> 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.

> 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!

View raw message