On Oct 8, 2004, at 2:05 AM, John Pierce wrote:

> Avi, we have several developers using GOODS.  Do we all need to
> upgrade and use WriteBarrier at the same time against the same GOODS
> databases -- or can we work in mixed mode (some of us trying
> WriteBarrier and others of us not trying it out)?

Mixed mode is fine.  All it affects is the client's choice of which 
objects to scan for modifications during a commit - without 
WriteBarrier, it scans the whole cache, whereas with WriteBarrier it 
just scans those that have been marked as modified since the last 
commit.  The data going to the GOODS database should be identical in 
both cases.

>> One thing you have to be careful of with this combination, for now, is
>> array literals - if you're ever storing an array literal in your
>> database, make sure to send #copy to it first.  Otherwise it's easy to
>> violate the restriction that any one instance can only be managed by a
>> single WriteBarrier.
>
> Are there any other kinds of literals to be careful of?

Strings and Symbols are by default assumed to be immutable, as an 
optimization, and so the WriteBarrier doesn't affect them.  Numbers are 
immutable as well, and are usually immediate values anyway (I doubt 
there are any LargeInteger literals in the image).  So Array literals 
should be the only issue.

>   Do you
> foresee that this will be handled by the framework eventually?

The best thing would probably be to force all literals to be immutable, 
as VW does - perhaps setting up ImmutableString and ImmutableArray 
subclasses and having the Compiler use those (and ImmutableMultiString, 
I guess?).  Then it would be quite easy for the framework to handle.  
Without that, you have the possibility that a single array literal 
could be modified separately by two concurrent transactions, which is 
bad news...

Avi