On 7/30/05, Scott G. Miller <sgmiller@xxxxxxxxx> wrote:
>
> On 7/29/05, Alessandro Colomba <acolomba@xxxxxxxxx> wrote:
[...]
> > I was wondering of you have ever considered the possibility of
> > orthogonal persistence in SISC, and if you have any caveats, or
> > thoughts in general.
>
> I haven't actually, its an interesting idea, but I'm worried about the
> performance considerations. I confess I'm not familiar with the state of
> the art there. I'd be happy to hear your thoughts on it, cross posted to
> sisc-devel if you don't mind.
Since this is a public reply, I should mention that orthogonal
persistence (OP) refers to the capability of a system to persist data
without explicit intervention by the program owning the data. If SISC
implemented OP, one could launch SISC, define a normal variable, shut
down SISC, reboot, relaunch SISC, and find that variable still
defined. Or, launch SISC on machine A, define a variable, launch SISC
on machine B, and find that variable defined. It's easy to imagine the
possibilities.
The "state of the art" of persistence in the industry is currently
represented by EJBs, JDO, Hibernate and the such. They offer different
degrees of abstraction over the persistent store, and neither
qualifies as completely orthogonal. That's OK, because whichever
persistence mechanism SISC were to use, it would be hidden from the
Scheme programs SISC interprets.The benefit of, say, Hibernate versus
EJB is that with the former one could reasonably expect to build OP on
top of SISC without changing SISC codebase much.
Performance-wise, these frameworks scale gracefully over hundreds of
concurrent users and over small clusters. With techniques based on the
locality principle (caching, object pooling, lazy load/storing, etc.),
they are in fact one-two order of magnitudes more efficient than naive
manual persistence. It is somewhat harder to measure their performance
in respect to no persistence at all, however, because so many setups
can be devised.
In general, programs that use serialization of closures as a mean to
communicate, such as SISCweb, would benefit immensely simply because
serialization is so inefficient. As you all know, closures are
serialized with their environment, leading to multiple copies of
shared objects.
I think making SISC's domain objects -- i.e. the Scheme heap --
persistent would turn out to be relatively easy for the RSR5 core.
Things become a bit more fuzzy in other areas however.
Java objects as seen from Scheme programs are not necessarily
serializable, and in the process they would lose their identity. One
could think of simply not serializing them on the grounds that they
are accessed and obtained through a FFI, and are therefore outside the
scope of the Scheme runtime. Middle-ground approaches are also
possible.
Resource descriptors such as ports, file handles, sockets etc. are
generally non-persistable as well. Also, they refer to local
resources, and it would be meaningless to allow them to be "picked up"
by a SISC instance running on a different machine.
Garbage collection in SISC, from my limited understanding, is snarfed
from Java. I can't see a clear, transparent way to have heap objects
automatically destroyed using the existing persistence frameworks.
Concurrency in SISC would probably need special attention in how it's
mapped onto the DB.
These are just initial thoughts. I should clarify that I have no plans
to actually attempt to implement this feature in the very short term,
but the idea is particularly appealing to me because of SISCweb. Plus,
this is an area in which SISC's being an interpreter would prove
particularly advantageous.
There is some ongoing research in OP at different levels of the stack.
In the Java world, Pjama is (was?) a project to add OP to the Java
runtime, for instance.
___
Alessandro
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
|
