Versioning and persistence

Chris Bitmead uid chris.bitmead@Alcatel.com.au
Wed, 21 May 1997 10:58:12 +1000


>>>>>> "Chris" == x22068  <Chris> writes:
>
>    Chris> What is most weird is what should happen when a old version
>    Chris> segment starts accessing another segment, and vice versa.

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

>In Gemstone each "session" essentially has its own "object table" tied
>to the state of the world when it began its current transaction. It is
>impossible to access one object from one "version" and another object
>from another "version". That would be illogical.

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

>The concept that Gemstone promotes is similar to a Smalltalk
>"image". A transaction is a unit of work applied to an "image" of
>objects that make sense as a whole. When the transaction commits
>successfully, it commits every object that has changed or it
>fails. The state of any particular object only truly makes sense
>within the context of all the other objects in that "image".

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

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