Message-ID: <3341296D.22D1@mail.amsinc.com>
Date: Tue, 01 Apr 1997 08:27:41 -0700
From: Tom Hawker <Tom_Hawker_at_AMS-Notes@mail.amsinc.com>
Organization: American Management Systems, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
Newsgroups: comp.lang.smalltalk
Subject: Re: Smalltalk OO databases -- how do they do it?
References: <33517954.952514733@news.jumppoint.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: simpm2
Lines: 35
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!uhog.mit.edu!news.kei.com!news.texas.net!cdc2.cdc.net!news.maxwell.syr.edu!news.sprintlink.net!news-peer.sprintlink.net!uunet!in1.uu.net!162.70.244.3!dns.amsinc.com!simpm2

Ian Upright wrote:
> 
> Smalltalk object databases can tell when an object's state has been changed,
> and know to persist those changes accordingly.  This begs the question, how
> do these databases efficiently detect these changes?  I can think of uses
> not relevant to persistence where it would be helpful to know if a certain
> object has changed it's state.  Is the implementation vendor/VM specific?
> Ideas on how to do this would be appreciated!
> 
> Ian

[This reply is specific to VisualWorks;  I don't know if it's true for
other Smalltalk systems.]

The general rule of thumb is to "adjust" the code, hiding the changed
source.  This is what GemStone does.  You can either manually in the
code perform a "self markDirty" to explicitly mark the object as now
having undergone a state change that must be flushed to the database, or
you can have GemStone look through the code of a class and subclasses
for setters to instance variables and "augment" the compiled method to
send #markDirty for every variable changed.  (This is done at the code
level, so the source is not affected;  you can see the results through
decompilation by holding down the shift key when you view the source.)

Obviously, the first solution is preferred, as the latter is completely
indiscriminate and has some significant performance hits.  (Each time
#markDirty is sent, GemStone has to do some cache management, object
locality control, and content synchronization.)  Further, it doesn't
handle unwind blocks that revert object state very well.

GemStone's way lets you at least be particular about which classes will
acquire such behavior.  For advanced programmers, you can really fine
tune dirtiness and state propagation.

Tom Hawker
