Here at GemStone we are working on adding transparent object 'persistence by
reachability' to JRuby. We have an industrial strength object database that
would serve as the persistent store, and we have run JRuby in our JVM and
have the persistence working. But we end up persisting too much because of
the attachment of JRuby objects to the runtime. Whenever an object is saved,
all objects reachable via its instance variables are also saved. When it can
reach the runtime via the 'metaclass' variable, we end up persisting way
more than we want, and trying to persist some things that are not
persistable (threads, for example). I realize that the coupling to the
runtime is a problem in supporting serialiazation/deserialization as well.

To decouple the object from the runtime when persisting: make the metaclass
instance variable in JRubyObject transient. This would go a long way toward
decoupling the runtime from the application objects. 

Reattaching persisted objects to the runtime when they come in from the
database would be more difficult. I am told that there have been ideas about
how to do this voiced in the past, but the issue has been deferred until
now. If we can solve this problem, we can offer a real, industrial-grade
object database as an alternative to ActiveRecord ... one that did not
require maintenance of a relational database schema and the migrations
associated with it.

One suggestion for reattaching a persistent object to the runtime: have an
accessor that lazily initializes the runtime connection. On the first
invocation after the object is loaded from the database, it would restore
the connection to the runtime. Both the overhead and the impact to the code
base would be minimal.

I admit that I have only browsed the source, so it is very possible that I
have missed something important. If so, I would love to be involved in the
discussion.
-- 
View this message in context: 
http://www.nabble.com/JRuby-and-GemStone-...-Transparent-Object-Persistence-tf3984748.html#a11313704
Sent from the JRuby - Dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply via email to