On Jul 9, 2004, at 3:03 PM, Chris Muller wrote:

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

Yes, I was expecting some kind of commit error.  I didn't get one, 
which is what surprised me.

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

Since my main interest in an OODB is in the context of web 
applications, having multiple (in fact, many) concurrent sessions in 
the same image is crucial.  If that's not a supported scenario, then I 
can't use it for web apps, period.  At least not until Squat brings the 
image overhead down to the point that running hundreds of image on a 
machine is feasible :).

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

That's interesting, because earlier in the test, I didn't need to cross 
a transaction boundary to see this.  That is:

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

So that set my expectations for later.

At any rate, I did *not* get a "key not found" error.  What appeared to 
happen was that the UI process simply died, and was then restarted, 
since although I was doing a printIt (or an inspect) on that statement, 
I never got any result back.  I have no idea what might be causing 
this.

Anyway, I'll try it with #abort and see if that makes any difference.

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

Got it.  Thanks for the explanation.
Just for reference: what I do in my GOODS client is to require an 
explicit #flush, which changes the normally strongly-held cache to a 
weakly-held cache, and then does a garbage collect.  This lets you 
manage the cache a little more directly, without being too onerous an 
API.

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

I agree that the image got hosed, or at least that session did.  But 
this was a totally fresh image, and I have described absolutely every 
thing I did in it.  So if I hosed it, I hosed it by using Magma in (I 
think) fairly normal ways.

I will try (not today) to put together a minimal script that reproduces 
the behavior I was seeing.

Avi