[squeak-dev] Magma and shared sessions.

Brett Kosinski fancypantalons at gmail.com
Thu Mar 27 17:09:40 UTC 2008

> Sorry Brett :)
>         the two images is nothing about Magma. You can if that is convenient for
>  you. I think it will depend more on the load limits (few seaside sessions per
>  image works better).

Which brings us back to the original question:  what's the best way to
manage those sessions?  Frankly, I'm a little unsure of the "correct"
mapping between Magma sessions and running Processes.  I'm also
unclear regarding how Magma manages session consistency (I get the
feeling that Auto sessions automatically refresh themselves at the
start of a commit:, but I'm not entirely sure about that).

>         By the way if you can set all in one image why use the tcp/ip at all?
>  Are you sure you need Magma at all? Do you have ACID kind of requeriments?

I have persistent storage requirements, and I'm not interested in
setting up a cron job to back up the Squeak image periodically (quite
frankly, I think that's a hack :).  I also have querying requirements
and made the assumption that a proper object database such as Magma
would be more appropriate for that kind of application thanks to
things like indexes.

In short, the TCP/IP service is injecting data into the database from
embedded clients reporting data, and then I'm building a Seaside
frontend for visual inspection of the data.  So, yes, I believe Magma
(or some sort of query-capable, reasonably fast persistent storage) is
the correct solution for this application (which is, in essence, a
very small data warehouse).

That said, this is just a small amateur project (I could've just
written up something in Perl or some other language/framework I'm more
familiar with, but I figured this would be a good vehicle for learning
Seaside development), so multiple images seems overly heavy-weight,
not to mention more tedious to manage.


More information about the Squeak-dev mailing list