Re: Serialization of PersistenceManagers

[Craig L Russell]

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:

at PMF has username and password, should they be serialized too?

I imagine that we have to serialize the PMF too, so if a connection defined

Craig

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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature