Versioning and persistence

[Patrick Logan]

>>>>> "Chris" == x22068  <Chris> writes:

    Chris> Oh good, someone from Gemstone. Is there anything you can
    Chris> tell us about how Gemstone does garbage collection on the
    Chris> database? I think Gemstone may be unique in this feature.

Gemstone is so unique among ODBMS that it is now marketed as an
"application server" rather than a database. It provides essentially a
multi-user Smalltalk execution environment with a large persistent
address space. Most ODBMS simply are bit servers to an application. We
store the methods and execute them on the server. Actually we can
migrate objects, their storage and execution at run time to multiple
servers and clients of various kinds. For example some objects may be
executing on an eight processor AIX machine, some on a two processor
Sparc, some on an NT server, and some on a Mac client Smalltalk like
Visual Works. Various shared object caches can be set up on any or all
of the hosts running a part of a Gemstone system.

So garbage collection is a big problem. There are multiple GC
strategies that span from typical generational strategies within a
process, to disk based strategies for large objects, on up to
"epochal" strategies for multiple users at run time, and
repository-wide strategies to collect objects that might not even be
executing in a transaction while they are being collected. This is one
of the products strengths and there are a number of proprietary
techniques that have been in development for fifteen years.

    Chris> I was more thinking of what happens when you have different
    Chris> segments/databases with cross pointers. Actually any
    Chris> situation with pointers there is always the question of
    Chris> whether you want pointers to access the latest, or the
    Chris> particular version they pointed to when created.

As I explained in my previous message, Gemstone maintains a consistent
"image" of all objects as of the point the current transaction
begins. There are no "different segments with cross pointers". All
objects are a part of the same starting "image" then some are modified
and if there are no conflicts with modifications from other users
during the transaction then all the modifications to all objects are
committed together. This is the gospel according to Gemstone.

Now having said that, here are two heretical situations:

(1) It is possible to execute a "continue" on the transaction. What
this does is (a) check for conflicts as if the transaction were going
to be committed; and if there are no conflicts then (b) not commit the
changes, but bring in to the "image" all the other changes that had
been committed to the repository while the current transaction has
been running. This is new within the last couple of years and has seen
little use so far.

(2) There is a layered product called "Gem Enterprise" which loosely
"federates" multiple Gemstone systems with a two-phase commit
protocol. Objects from another Gemstone system can be copied, proxied,
etc. with varying degrees of security and refresh and modification
policies. This has just been released as a product, so has not seen
much use outside of a beta evaluation.

    Chris> Most people on this mailing list want to have a single
    Chris> address space for all users. Personally I'm not fully
    Chris> convinced this is desirable, but seeing as everyone wants
    Chris> it, it seems to conflict with the notion that every process
    Chris> has it's own view on the world, and it's own, potentially
    Chris> different state of objects.

    >> Jumping on to this list only today, I am assuming a LispOS
    >> "image" would be single user, or at least multiple users
    >> affecting a single "image". That simplifies a lot of things.

    Chris> Are you sure? How will different users views on the world
    Chris> interact in the context of versions and transactions?

I meant it would simplify the implementation, not necessarily the
programming model, assuming everyone interacts with the same "image",
to use Smalltalk terminology. It would probably be best to start with
something like RScheme running the Texas persistent store. Objects
could be "remoted" to other systems using something like Kali Scheme's
notion of first-class address spaces. It would be interesting to have
a secure set of resources made available within those address
spaces. For example, some address spaces could have a window system,
some address spaces could be "detached" and reattached some long
period of time later, etc.

-- 
Patrick Logan                 mailto:patrickl@gemstone.com
Voice 503-533-3365            Fax   503-629-8556
Gemstone Systems, Inc         http://www.gemstone.com