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
magma@lists.squeakfoundation.org