[Seaside] About SToR

[goran at krampe.se]

Hi!

(back from vacation now)

Ramon Leon <ramonleon at cox.net> wrote:
> > Our experience so far is that Magma currently works very good. We have
> > had no corruption and I have only discovered two bugs so far, one only
> > affected performance and the other only appears during heavy debugging
> > etc and I am not even sure it is Magma's fault. We are now beginning to
> > work with the index and multi-index query capabilities that is recently
> > being added - and it looks very nice.
> > 
> > I have worked with GemStone quite a lot (both St and J) and I think
> > Magma gives almost the same, but with a much simpler architecture. The
> > fact that it is all Smalltalk with source is also a bonus.
> > 
> > There is one scalability issue that we are mulling a bit and that is the
> > fact that the sessions are not sharing persistent objects at all. But
> > with some appropriate stubbing I think that can be avoided as a problem.
> > Best would of course be if Magma somehow magically could share objects
> > between sessions, as long as they are unmodified - but as you can
> > imagine that is a hard problem.
> > 
> > Anyway, this app will be published soon and I think it can be used as a
> > nice "real world example" or perhaps even be stripped down and
> > complemented with a tutorial it could form some kind of
> > WebAppInAMinute-bootstrap.
> > 
> > regards, Göran
> 
> Besides the app itself, which is great btw, I'd love to see a more 
> detailed write up of your experiences building it, and more generally, 
> ODB's and the mindset one needs to use to work with them.

Yeah, I intend to write quite a bit about it.

> What made you decide to use a session pool rather than have a magma 
> session per Seaside session?  Is any of the stuff you've built to marry 

Currently we have a compromise - we use one magma session per Seaside
session, but it is allocated from a pool. This means we cut out the
session creation time, but more importantly - the session is "hot" so we
keep the cached objects of the session.

But the problem with using one Magma session per Seaside session (which
thus remains for us) is that if you have a large persistent domain model
AND you wish to cache quite a bit of it - then you get:

	numberOfObjectsInRAM = numberOfSeasideSessions *
objectsCachedPerSession

So if you have 100 concurrent sessions and 10000 objects cached per
session you get a million objects. Ouch.

One approach I have been toying with in my head is to use a single
readonly Magma session and let all Seaside sessions share it. That
session could then be allowed to cache a large part of the domain model.
Then - when you know that you are going to modify something - you
allocate a new session from the pool (or create a new one) and perform
the Magma transaction using that one instead.

But there is one tricky problem - when do we update the shared Magma
session and its cache of objects? Seaside/KomHttpServer is serving using
multiple processes (which might be a problem in itself btw, but we could
protect the session using a Monitor) so we do not have a natural point
in time when we could refresh the session.

One idea that surfaced before going on vacation was to use TWO readonly
sessions and then have a global flag that we set whenever we make a
Magma transaction modifying the db. All Seaside sessions then use
readonly MagmaSession A, and when a modification is made we issue an
abort to MagmaSession B (which noone uses) and the ongoing Seaside
sessions can continue to run using A. When B is refreshed we migrate all
Seaside sessions over to B.

The above approach means that we get a possible delay before the
modifications are visible to the users, but it should be small. I still
need to bounce the above idea on Chris Muller (Magma author) and see
what he thinks.

And finally - yes, this is a bit of "premature optimization" but 100
concurrent users for this app is actually a reasonable number.

> Magma to Seaside general enough that it could be used with Goods and 
> Seaside?

The "integration" part is very small. Just a hook to abort the session
at the beginning of the HTTP request. One optimization we have done is
that we only abort if a global flag has been set showing that there
actually has been a modification to the db since the last HTTP request.
This would obviously not work in a multi image deployment scenario - but
we got rid of the MagmaSession abort penalty for most of the requests
(and I believe it gets aborted twice because Seaside typically does a
redirect on each request).

>  Could there be a small Seaside persistence framework there, 
> that could allow the ODB to be pluggable?

Well, I have implemented such "facades" on a few occasions before but
typically you end up having to cheat in the end anyway. And we don't
have that many ODBs to choose from. :)

regards, Göran