Some questions

[goran at krampe.se]

Hi Chris and all!

As some of you heard I am busy building a pilot of an issue tracker at a
customer. I am using Seaside, Magma, Kilaeua and probably Mewa. Being an
old GemStone lover it is really, really nice to finally be able to use
Magma for real.

The application I am building will approximately take a man-year to
complete fully, some info:

1. 350+ total number of users, perhaps 50-100 concurrent.

2. The current old tracker has 10000+ issues in it which has been
collected over 2-3 years I think. These will be migrated so we are
starting at 10000+ and working upwards from there. :)

3. The new system is intended to support offline operation, meaning that
users will be able to make a standalone installation on their laptops
and then replicate a portion of the model to it, work offline, and then
sync up later. I will be using a "prevaylerish" pattern to accomplish
that, or call it a Command pattern if you like. I also note the
existence of Magma's forwarding proxies (might get handy). So yes, the
laptops will in that case run a local Magma with a subset of the full
db.

4. The spec is written by me, about 30 pages. It includes some pretty
advanced meta facilities, workflow graph, permission model, dynamic
forms, subscriptions/notifications, scripts yaddayadda. Perfect for
Smalltalk, Magma, Seaside of course.

Now, after having gotten my few first lines of code running (stealing a
bit from Cees' Nags app) and getting a grip on the current strategies
chosen by Kilauea and Brent (MagmaSeaside integration) I have some
questions regarding sessions:

Kilaeua has a connection pool so for each request a Magma session is
picked from the pool and the whole request is wrapped in a Magma
#commit:. Then the session is released back into the pool. This means
that we will only have as many Magma sessions as we allow concurrently
served requests. This is of course a far smaller number than the
currently logged in users, in my case perhaps 10-20 (just from the hip).
Note: the pool seems like a handy addition to Magma, but we can discuss
that when it is fully battle tested and commented. :)

Brent's code (MagmaSeaside integration) uses one MagmaSession per
Seaside session I think. This would in my case potentially turn out to
be 100...

Now my questions:

1. Regarding wrapping each request in a commit - how costly is that? The
abort/begin is of course needed (and how much does an abort cost if no
modifications have been made?), but how much does the commit cost if I
say do no modifications but have a large "read set"? I am guessing this
is much cheaper if I use WriteBarrier? Is the WriteBarrier code fine to
use?

2. Most of my requests will of course be readonly. Would a different
approach be interesting - like for example, all requests share the same
"readonly session" and if they don't end up doing modifications (the
developer needs to know of course) - it is fine. This would mean
multiple Squeak processes using the same Magma session - which I guess
is fine as long as I protect the calls to the session object and make
sure my domain model is thread safe (but since we aren't doing
modifications it ought to be). Then - when a request decides to actually
change something - it would allocate another session from the pool, make
the modification, and release that session.

Most kinds of objects in my domain model will be few enough to
agressively cache - but 10000+ issues replicated over 10-20 or even
worse - over 100 Magma sessions is a bit too much. The above approach
(using a shared readonly session with an aggressively cached model, and
then have 10-20 other sessions in a pool for actual commits) would
typically save a lot of ram and also avoids the unneeded commit at each
request end. It could also use fewer aborts by simply using a shared
"some just performed a commit"-flag and then only do an initial abort if
that flag is set.

3. ...and finally - if I don't hold onto my domain objects, but only the
session - will they be gc'd? I assume this since I think the session
uses Weak structures to hold the objects. So if I want to explicitly
"hold onto" parts of my model - I would need to do that myself I assume.

Thanks in advance for any replies. And yes, this is all "premature
optimization" - but I just want to make sure I don't code myself into a
corner. And I want to hear what other people are doing. :)

regards, Göran