[elephant-devel] Transient slots in non-persistent objects

[Peter Bengtson]

Hi Ben,

There is nothing wrong with using persistent objects throughout the 
application - I may indeed go that way in the end - but at the moment 
I'm trying not to tie the database model to the application to closely. 
It should, ideally, be possible to use any one of a number of 
persistent storage methods.

The database will probably be kept in memory - I'll rely on the OS to 
handle the memory issues through VM - so the storage overhead of 
caching OIDs and keeping buffers for detecting circularities, etc, is 
something I wish to avoid. And objects and their slot valus need to be 
compared through identity.

There are two ways to go: either follow the minimalist approach, or 
embrace persistence entirely and use it throughout. Or, in other words, 
use a memory-based or a disk-based approach. For now, I want to keep to 
the memory-based approach, but this may well change later.

A thought struck me: looking at #'slots-and-values in serializer.lisp, 
I see you are using #'compute-slots, a generic function, to obtain the 
names of the slots to be saved. Wouldn't it be possible to simply 
specialize on #'compute-slots to obtain the effect I'm after?

	/ Peter


2004-10-20 kl. 17.42 skrev Ben:

> At the moment, there is no way to make transient slots on ordinary
> objects.  On first glance, I don't know how to support non-standard
> slot options in the standard slot metaclass.  The serializer uses
> "slot-value", not the accessors, so I think unless OpenMCL calls
> "slot-value-using-class" (which I don't remember off the top of my
> head) you'll have a hard time overriding that.
>
> There are some other kludges I can think of, but they are just
> kludges, roughly equivalent to the one you've suggested.  One thing
> you can do is keep track of the objects which hold OS resources.  For
> example, you can put something in initialize-instance which adds the
> instance to a collection stored somewhere on the class object.  (EQ
> hashtables are probably good for this.)  Then you can have a method on
> the class object which walks the collection and NULLs the offending
> slots.  Call this before shutdown / save.
>
> Honestly, your usage pattern wasn't one I had in mind when Elephant
> was designed.  Some of your concerns might be fixed by
> "single-user-mode", but unfortunately given time constraints that
> probably won't get done until at least the end of November.  Can I ask
> what is wrong with using persistent objects?  Is it caching (DB hits
> on read), DB hits on write, or lazy loading?
>
> You might consider flipping various flags on the DB for performance,
> like DB_PRIVATE, DB_TXN_NO_SYNC, etc.
>
> take care, B