Single User vs Multi User quetions
goran at krampe.se
Fri Feb 27 09:02:59 UTC 2009
Milan Zimmermann wrote:
>>> It sounds like when I want to have more than 1 connection (session) to
>>> Magma, I have to use the "Server/Client" connection mode described there
>>> - the single user mode would not allow 2 correctly functional sessions,
>>> is that correct?
>> No, you may have many locally-connected sessions. Which part of the
>> documentation "sounds like" otherwise?
> Well, I misread. I realize "single user" is not equivalent to "single
> session", this is what I misread:
> "Single-user mode
> If you know will be operating in a single-user environment, starting a second
> image to run the server may not always be convenient."
> I inferred that multi user requires client/server environment, (which can run
> in single or multiple images - I hope I understand correctly that this is
> true), but I erroneously assumed
> "single user" = "single session."
I am not entirely sure you got it. :) If I rewrite what you wrote it
seems you say "a client/server environment running in a single image"?
That sounds like a contradiction, depending on what you mean with
"client/server" of course.
Let me try to explain this as I understand it :)
Magma can always have multiple sessions and one session typically
corresponds to one user (or other process that works with the db). In
Gjallar we have one session per logged in user + one session per
frequently running background service.
One way to run Gjallar is using a single image - this is the "local"
configuration. All sessions (MagmaSession instances) live in the same
image and communicate with the "server parts" (MagmaRepositoryController
etc) in the same image that in turn write to disk.
Each session creates its own "copy" of the domain objects that are
loaded from the db, since it needs to be transactionally consistent for
that session (regardless of other sessions doing txns).
This is a very nice way to use Magma when developing and this is how
Gjallar has been developed (and even deployed!) most of the time.
The next step is to separate the "server parts" of Magma into its own
image. The obvious reason to do this is in order to have multiple images
running with say 5-10 MagmaSessions in each. This is a classic way of
scaling a webapp. Use say 5 images with 5-10 users per each (use a load
balancer in front, like say Apache) - have each of these 5 images
connect to a single Magma server image that in turn writes to disk.
One funny thing is that splitting out the Magma server into its own
image actually seems to improve performance even when using just a
single "client" image! So the network communication is obviously not a
The latest High Availability stuff in Magma means that you can take this
another step and create "slave servers" that continuously mirror the
master server and are readonly and can thus offload read operations from
the single master server image. Definitely nice and should help scaling.
More information about the Magma