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

You are not first person to ask about this and I'd like to discuss it with you.
 First, let me express my understanding about one of the implementation
side-effects of using any OODB in a web-server.

In Java/Oracle web architectures I've worked on have a single domain model in
memory that all web-sessions "collaborate" on.  The relational db may or may
not be used for concurrency detection.  You can do this with an OODB, by having
multiple web-sessions each sharing a single MagmaSession (or GoodsSession) but
you would not have concurrency detection.

To have concurrency detection, you would have one MagmaSession for each
web-session.  But that means each session has its own view of the domain model,
and can they "collaborate" only through the database.  This is much slower, and
also leads to having *multiple copies* of some of the same objects.

So it seems you would really need to take care to keep memory consumption down
by employing well-considered read-strategies and also stubOut: objects
agressively (which may also affect performance since it uses become:).

I'd like to hear your comments about these implementation challenges..

Despite these hurdles, I think it *should* actually work.  In fact, I think it
should work out of the box right now.  If it doesn't, I'd like to know why and
get it working if there's an issue.

But I need your help, Avi.  Web apps have not been a priority for me just yet,
so I don't have a good feel for what test-script would be adequate to prove to
you that it works.  You do.

If you can articulate a detailed test script involving multiple sessions in the
same image that will satisfy you, I will incorporate it into MagmaTestCase. 
The easiest thing would be if you could write the actual script in a workspace
(i.e., with your temp vars, "client1 client2 client3, etc" all doing all the
concurrency and multi-process things you want.

 - Chris