On Tue, Jul 06, 2004 at 04:16:47PM +0200, Adrian Lienhard wrote:
> I had a similar problem when using sets with GOODS. (I used #includes: 
> which sometimes worked and sometimes didn't). The problem is the 
> following: GOODS treats sets like other objects by storing their 
> instance variables (which is an array and tally for sets). When 
> bringing sets back into the image, the array is restored as it was 
> saved. But the implementation of sets depends on the order in which 
> values are stored in the array. And the order depends on the hash value 
> of the objects. Now, when GOODS reinstantiates the values of the sets, 
> they are different objects and thus have different hash values!
> 
> I chatted with Avi and the simplest workaround we could think of is to 
> send rehash when GOODS instantiates a set. That solves the problem but 
> it is suboptimal: The rehashing modifies the set which then gets 
> written back on each commit. This made the workaround for me unusable 
> because too many write conflicts occurred.
> 
> I can send you the code for the workaround if you like.
> If somebody has a solution I would be interested. For the moment, I 
> just avoid storing sets in GOODS...

Very interesting Adrian, it does indeed seem to be the problem here
(digging around remove: does match your description)  I guess the best
thing to do right now is follow your example and get rid of the sets.
-- 
Ragnar Hojland - Project Manager
Linalco "Specialists in Linux and Free Software"
http://www.linalco.com  Tel: +34-91-4561700