I haven't had time to test and verify everything just yet, but I'd like to
comment initially because I see there appears to some discrepencies between
your expectations and how it works.

> 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?

Just an FYI, if you look in MagmaTestCase>>performCommitConflictTest, you can
see that concurrency is part of the normal test case.  It has worked for a long
time.  However, just looking at this I think a MagmaCommitError should have
been signaled.  Perhaps you have found a bug!  I will research this this
weekend and let you know.

One thing to note, however, that having multiple sessions in the same image is
not specifically supported, although I see no reason it shouldn't work. 
MagmaTestCase actually uses two separate client images and one server image to
do the test, so maybe the single image is the cause of the anomaly your seeing
but I'd be surprised if it was.  I'm very curious, I'll let you know.

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

While most of Magma's general-usage API is through MagmaSession,
commit-conflict detection is not.  To get an overview of Magma's API (or the
API for any package, for that matter), I suggest using a Package-Pane browser. 
Go to the "Exceptions" category of "Magma client".  In there, you see something
called "MagmaCommitError".  Use on:do: to capture this error and retry, if you
wish.  See the aforementioned testcsae method for an example.  The signaled
exception has a #result attribute which is a MaFailedCommitResult, which can be
queried for the exact objects that were in conflict and who session changed
them.

> 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...

Yes, 2.9 seconds on my Pentium III 700MHz laptop.  Faster computers will yield
faster results, of course, especially for clients.

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

I just tested this and I correctly get a "key not found" error.  That's because
mySession2 hasn't crossed a transaction boundary.  Just as in GemStone, the
view of the db for any client is only refreshed upon a commit or abort.  Since
you didn't do this for mySession2, the correct response is "key not found"
which is what I got.

> ..mySession2 root at: 'test3'..

The correct response for this is also "key not found", which is what I got. 
Since you also had a problem with the retrieval of 'test2' I suspect something
is wrong with your image.

I just did:

  mySession2 abort.
  Time millisecondsToRun: [ self root at: 'test2' ]   "--> 599"

So it was a little faster on the "initial" retrieve than GOODS, even with my
slower PIII laptop.

> Try it again, expecting it to be instant (since the objects 
> should be cached now), but get ~300ms every time.  Interesting - why is 
> that?

Magma only caches the root for brief periods if it is accessed in the middle of
a transaction.  Other than that, NOTHING is cached unless you maintain a
reference to it.  Weak collections are used, so if you have a reference to the
collection at 'test2' it will hang around.  So what you need to do is:

  |r|
  r _ mySession2 root.
  Time millisecondsToRun: [ r at: 'test2' ]

I get 0 milliseconds.   :)

It isn't smart to hold onto the root in Magma because nothing would be garbage
collected and memory consumption will continue unless you specifically use
#stubOut:.  Instead, you more realistically cache only the objects you need
very frequently.  And you do it merely by referencing it, there is no #cache
api with Magma.

So after all this, the only anomaly I encountered is that it didn't notify of
the commit failure.  I *will* research this and have an answer to you this
weekend.  As far as your session2, I think your image got hosed up or something
because everything else worked perfectly for me.  If you can reproduce it with
a straight-run script, I'll research it and have an answer back to you quickly.

> Chris, is this useful?  Should I continue?

Yes very useful, thank you!  Please do continue.  I'd want to get any bugs
fixed and unexpected behaviors clarified.  Using an OODB that you're not
familiar with, or any db for that matter, is going to take a little time and
commitment to learn and get familiar with.  I think once you reasonably
allocate a few hours to familiarize you may find the behaviors more natural;
and I'm here to help anyone along who has questions.

Cheers,
  Chris

PS - I will also look into your first "Magma notes", I see you've nailed me on
that darn MaFilename.  I've hated that class since the beginning, I'll see if I
can finally get rid of it.