[Setools] Re: Counter in Gjallar

[Keith Hodges]

Göran Krampe wrote:
> Hi Chris!
>
>   
>> Hi Göran, no, I'm sorry to hear that since I spent a good 4 days on it
>> and ended up quite pleased with the result.
>>     
>
> No need to be sorry! :) I haven't looked but IIRC from your post you
> implemented an RC counter a la GemStone, right? Which is quite useful for
> counting stuff of course. :)
>
>   
>> What's the problem with it?
>>     
>
> Well, we have multiple MagmaSessions creating Q2Txn objects, giving them a
> strictly increasing unique number and adding them to a MagmaCollection. In
> short we want the illusion of a very long OrderedCollection. :)
>
> In an OrderedCollection each object of course has its position and if you
> succeed adding an object to it (without conflicts) then its number == its
> position.
>
> With a MagmaCollection we need to give it a number ourselves (and use an
> index for it) - and the problem is how we generate that number so that we
> don't end up with multiple Q2Txns with the same number - and not having to
> do multiple commits.
>
> In other words - an "integer series generator" is not exactly the same
> problem as a "reduced conflict counter". Note btw that I am describing
> this from MY understanding - Balazs and Levente are the ones who are
> coding on this and perhaps I have misunderstood some parts :)
>
> The "simplistic" solution is of course to let all MagmaSessions make a
> server call (to the Magma server) which has a counter wrapped up in
> critical: blocks for increasing it. Thus making sure we serialize all
> "increments". This is what Keith implemented which apparently did not work
>   
I simply implemented a request-response which uses the existing 
protocol. It has a class which handles both ends of the communication. 
Of course this class (these classes) has to be present in the server for 
it to work. This effectively bypasses the database altogether, so there 
are no critical blocks involved. Since the server handles requests 
serially it does ensure that the counter does not conflict.

The bit that I did not know how to do was  how to persist the counter 
values. I just used a file on the server to serialize read/ unserialize 
write a dictionary with the counter values in it on every increment.

I myself have not looked at MagmaCounter yet.

> in the Magma version I tried a week ago (the server seems to not deal with
> the MagmaServerRequest properly when running as a separate image - causing
> the client image to "hang" waiting for a response. I logged all Magma
>   
The server image has to have the responder classes loaded in order to 
respond.

> requests going and all seems fine until this "MagmaServerRequest" coming
> through the line, haven't debugged it further on the server side - failed
> to see where to put the darn halt. :)).
>   
best regards

Keith