Versioning and persistence

[Chris Bitmead uid]

>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.

And what are those proprietary techniques? :-) :-)

>    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.

What does Gemstone do when obj A points to obj B and obj B gets
updated to a new version. Does obj A point to the original version or
the latest version? Whichever way Gemstone does it, what if that
wasn't what you wanted?