I have just posted my initial solution to this problem to the MagmaTester project known as the configuration "r41Alpha1".
After thinking about the problem, it really boils down to you want a syncronized application function. Therefore I have introduced MagmaSession>>#executeInServer: oneArgBlock to run an arbitrary block of code in the server's session, with full access to the persistent model.
mySession executeInServer: [ : repositoryController | repositoryController session commit: [ ...increment your counter... ] ]
This brings radical new power to Magma, teasing with the idea of an "application server" not just an object server. But there are caveats. For now, it was just the easiest and cleanest way to get what you want; it was so simple I was able to implement it over my lunch hour. Gorgeously, it leverages all existing functionality and integrates into the entire system seamlessly without introducing any new special-cases. But there are caveats.
I also included a test case that proves it works across multiple clients in separate images connected to a remote server each grabbing #getNextKey as fast as they can and then verifying they got no duplicates between them and that their union is consecutive and complete.
See MagmaTestCase>>#testSequenceNumberGenerator. You may also use it as an example for how you can implement it for your Q2Txn's. However, note you don't have to use a MagmaCounter the way the test case does, if you don't want to. You could simply use an Integer that you commit: [ nextNumber: self nextNumber+1].
Enjoy, but please don't use this radical new power for anything else; I can't promise I will keep this as the solution because.. there are caveats..
On 8/22/07, Göran Krampe goran@krampe.se 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 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 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. :)).
So.... best would be if you, Keith, Balazs and Levente came up with a solution. I am ccing them all here (don't have Levente's email handy but Balazs talks to him). Also - I started installing r40Gamma2 (or was it 3?) last night but haven't had time to test it in this regard yet.
regards, Göran
PS. Martin McClure from GemStone has contacted me and they are interested in porting Gjallar to GemStone/S! If they go through with that we end up with a formidable comparison platform for Magma vs GemStone. We will not leave Magma of course - no worries there - Gjallar is open source and we also have our offline mechanism which demands an "embeddable" db like Magma. And in most respects it works really, really good and I hope Gjallar will become the MAJOR poster app for showing what Magma can do.
Reply Reply to all Forward Reply Reply to all Reply to allForward Forward Print Add Göran to Contacts list Delete this message Report phishing Show original Message text garbled? Göran Krampe to me, magma show details Aug 24 You're Da Man Chris! :)
regards, Göran
Reply Reply to all Forward Invite Göran to Gmail Reply Reply to all Reply to allForward Forward Print Add Igor to Contacts list Delete this message Report phishing Show original Message text garbled? Igor Stasenko to goran, me, magma show details Aug 24 I implemented 1:1 as in the sample code in test. And its not working :/ Raising commit error in the middle of Db creation. I don't know what is the cause (the Q2Counter code is fairly simple to make something wrong). Maybe we need some additional changes in gjallar code to conform with latest magma version. Also, if using old code, all works ok - simple gjallar DB created and populated without errors, but once i using executeInServer: it stops with error. I'm not too high expert in magma to suppose what is wrong. I submitted snapshot with new Q2Counter code into gjallar repo, give it a try.
On 24/08/07, Göran Krampe goran@krampe.se wrote:
You're Da Man Chris! :)
regards, Göran
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
-- Best regards, Igor Stasenko AKA sig.