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
Hi!
Keith Hodges keith_hodges@yahoo.co.uk wrote:
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.
I used an identical image as server (as the client). It has the responder classes in it.
regards, Göran
setools@lists.squeakfoundation.org