After talking with Charlie about an approach, we decided that this is
what we would try first. It would require an additional 4-byte field
in every object. Not the optimal approach, but good enough for a
proof-of-concept.
1) Mark 'metaclass' and 'finalizer' transient. This should allow us
to persist an object without dragging the runtime classes along.
2) Add a String 'metaClassName' field to RubyObject. Initialize it in
setMetaClass() when it is first called.
3) Modify getMetaClass() to lazily initialize the metaclass variables
when the, using 'metaClassname' when the getter is first called.
Here's an alternative approach that I would like some feedback on.
It's more complicated but would not require any additional instance
fields. It would add a field to the metaclass instead.
1) Mark every field in the RubyClass transient except for one: a new
'metaClassName' field. Initialize it when the metaclass is created.
When saving an instance, save the metaclass in the database, too.
2) When the object is reloaded from the database, fault the persisted
metaclass into memory on the first instance method invocation.
3) Use lazy initializers on the metaclass fields reconnect to the
original metaclass's field references. This would mean that there
would be two identical classes: the new one hooked up to the
persisted objects (it would be the start of method lookup for
persisted objects that had been reloaded) and the original class that
would continue to be used to create new instances. Not-yet-persisted
objects would use the original.
Ideas? Comments?
On Jul 4, 2007, at 10:19 PM, Charles Oliver Nutter wrote:
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
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
