Single User vs Multi User quetions

[Göran Krampe]

Hey!

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 
big deal.

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.

regards, Göran