r41Alpha1 (was: Re: Counter in Gjaller)

Sat Sep 1 04:18:00 UTC 2007

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 at 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 at krampe.se> wrote:
> You're Da Man Chris! :)
>
> regards, Göran
>
> _______________________________________________
> Magma mailing list
> Magma at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/magma
>

--
Best regards,
Igor Stasenko AKA sig.