Jochen Theodorou wrote:
you mean the new object won't be connected to the runtime, because it was deserialized by Java? I see.. hmm... my next thought is a bit complicated, but well... Let us assume all Runtimes register themselfs at a global map using a unique id. Then, when deserializing the object, the runtime is created using this id and registered at the new computer or attached to an already existing id. java.util.UUID might help here, but I don't know if it will work. I never worked with UUID.
Usually the case is that JVM 1 and JVM 2 start up independently and create their own runtimes before any of the persistence magic begins. So when you're interested in deserializing objects on the other side, you need some way to reattach them to a given JVM.
I hate to steer away from this specific example, but I'd like to hear more from the Gemstone guys about the various ideas thusfar. Since it sounds like you control the persistence endpoints, is it such a big deal to make a runtime available on the other side?
If we decided to continue down the path of detaching objects completely from the runtime, do you have any proposals for resolving the requirements I set forth earlier?
- Charlie --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
