(Continuing my notes on installing and using Magma)

Ok, now that the server is up and running, switching to the client 
image.  I create a session with:

  mySession := MagmaSession
     hostAddress: #(127 0 0 1) asByteArray
     port: 51969.
   mySession connectAs: 'avi'

And follow the instructions on the wiki to commit something to the 
root.  No errors.
I create a second session and try to pull my data out of the root.  
Success!  Great.  That was easy.

I try modifying the root in mySession2, and then inspecting it in 
mySession.  The change came across.  Cool.

Ok, let's try some concurrency.

	mySession begin.
	mySession root at: 'test' put: 7.
	mySession2 commit: [mySession2 root at: 'test' put: 8].
	mySession root at: 'test'  "==> 7"

Good - we're inside a transaction so we don't see the change from 
mySession2.  What if we try to commit?

	mySession commit.

No errors... what happened?
	
	mySession root at: 'test' "==> 8"

Ok... so the commit clearly failed, due to the conflict with 
mySession2, which is what I would expect.  But is there a way to get a 
notification of this?  I would probably want to retry the transaction 
when this happened.

Browsing through the MagmaSession protocol looking for a way to get 
this, nothing jumps out at me.  Chris?

Next, try some performance tests.  Commit a medium sized 
OrderedCollection:

	Time millisecondsToRun: [mySession commit: [mySession root at: 'test2' 
put: ((1 to: 1000) collect: [:i | i at i])]]

Executes in 2.4s.  That's pretty good.  What about to retrieve it?

	Time millisecondsToRun: [mySession2 root at: 'test2']

Hm... very strange things are going on.  This seems to fail silently - 
I never get a number back.  Inspecting mySession2 root shows only 
'test' as a key.  #basicInspect shows the same thing.  I try 
"mySession2 root at: 'test3'" and get an emergency evaluator, then try 
it again and get the same silent-failure behavior.  This doesn't bode 
well.

Ok, let's try this with a third session.  Aha, that worked: 621ms to 
retrieve.  Try it again, expecting it to be instant (since the objects 
should be cached now), but get ~300ms every time.  Interesting - why is 
that?
I'm also curious how many of the objects in the collection actually got 
brought in during that 621ms.  Let's try to force them all in:

Time millisecondsToRun: [(mySession3 root at: 'test2') do: [:ea | ea 
yourself]]

Again, about 300ms each time.  Ok, I clearly don't understand the 
caching model here.

Since I'm doing some timings, I might as well compare this to GOODS.  
Start up a GOODS image...

Time millisecondsToRun: [db root at: 'test2' put:  ((1 to: 1000) 
collect: [:i | i at i]). db commit]

1.6s.  Not too different.  And retrieval?

Time millisecondsToRun: [db2 root at: 'test2']

GOODS gets 15ms on the first run, 0ms thereafter.  Again, let's force 
it to bring everything in:

Time millisecondsToRun: [(db2 root at: 'test2') do: [:ea | ea yourself]]

727ms the first time, 3ms thereafter.  Two things we seem to be seeing 
in GOODS but not in Magma: not bringing in all the objects until 
they're needed (it only took 15ms to bring in the collection itself, 
the big hit wasn't until accessing its members), and caching the 
objects once they're there.  Chris, how could I get Magma to do the 
same things, if I wanted to?

Ok, that's enough for part II - time to grab some lunch.  I especially 
want to know what happened to mySession2, which seems to be permanently 
hosed now.  Any thoughts?

Chris, is this useful?  Should I continue?

Avi