Hi,
Continuing with the examples in
http://wiki.squeak.org/squeak/2689
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?
Also a follow up question: I am not sure how to understand the following:
"While your session is connected, it is recommended you keep up-to-date every 30 seconds or so changes made by other users will be reflected in the objects you visit."
Thanks Milan
Hi,
Continuing with the examples in
http://wiki.squeak.org/squeak/2689
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?
Also a follow up question: I am not sure how to understand the following:
"While your session is connected, it is recommended you keep up-to-date every 30 seconds or so changes made by other users will be reflected in the objects you visit."
Changes by other users are not visible to a session until it crosses a transaction boundary with #begin, #commit or #abort.
- Chris
Hi Chris,
Thanks for your comments - my notes inline:
On Monday 19 January 2009, Chris Muller wrote:
Hi,
Continuing with the examples in
http://wiki.squeak.org/squeak/2689
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."
Also a follow up question: I am not sure how to understand the following:
"While your session is connected, it is recommended you keep up-to-date every 30 seconds or so changes made by other users will be reflected in the objects you visit."
Changes by other users are not visible to a session until it crosses a transaction boundary with #begin, #commit or #abort.
ok, that is clear,
Thanks, Milan
- Chris
Ah, yes, I was a bit loose with the "session" vs. "user" nomenclature. This matters in the context of a web-server app, sorry!
I was equally loose in my other comment:
Changes by other users are not visible to a session until it crosses a
transaction boundary with #begin, #commit or #abort.
which should more precisely be stated as,
"Changes by other *sessions* are not visible to a session until it crosses a transaction boundary with #begin, #commit or #abort."
Regards, Chris
On Tue, Jan 20, 2009 at 12:26 AM, Milan Zimmermann milan.zimmermann@sympatico.ca wrote:
Hi Chris,
Thanks for your comments - my notes inline:
On Monday 19 January 2009, Chris Muller wrote:
Hi,
Continuing with the examples in
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."
Also a follow up question: I am not sure how to understand the following:
"While your session is connected, it is recommended you keep up-to-date
every 30 seconds or so changes made by other users will be reflected in
the objects you visit."
Changes by other users are not visible to a session until it crosses a
transaction boundary with #begin, #commit or #abort.
ok, that is clear,
Thanks, Milan
- Chris
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
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
Thanks for the excellent description Göran, you are right on. Although, I am a little puzzled by a separate Magma server image that would be faster than a locally-connected one. That seems impossible, due to the the serialization/materialization of the request/responses work to do in the former.
I would also like to mention the next and final tier of scaling up with Magma. Yes, the new HA feature of r42 has a nice side-effect of improving read-scale, but there is also a tool for improving read and write AND memory scale; MagmaForwardingProxy. The goal ForwardingProxies are to create the illusion of a giant interconnected "logical" repository, hosted by multiple physical servers.
The programming pattern is very simple, in the setter of an object that links to an object in another repository, you simply send #asMagmaForwardingProxy to set to a link rather than the actual object. For example, in a network-provisioning application, you may wish to keep the UserAccounts in a separate repository from the provisioned Connections. Therefore, in VirtualConnection>>#billingAccount: aUserAccount, you might have:
billingAccount: aUserAccount billingAccount := aUserAccount asMagmaForwardingProxy
Each MagmaForwardingProxy knows its location, so when the billToAccount is sent a message, the ConnectedSessions global is searched to see if there is already a session open on that location, otherwise one is allocated dynamically. Therefore, this is also useful for improve memory-scale to share "control" data objects that don't change often, between many sessions (something you specifically asked me about before, but I didn't have enough clarity about the ForwardingProxies at the time to have mentioned it!).
I have always advocated using MagmaForwardingProxies as a way for partitioning the domain by type, but in reality you can cut the model any way you want. For example, in our application we use the last-digit of an Id to determine which repository it will go into, which we hope will provide up to 10X improved read and write scale over putting them all into a single repository.
- Chris
On Fri, Feb 27, 2009 at 3:02 AM, Göran Krampe goran@krampe.se wrote:
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
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
magma@lists.squeakfoundation.org
-
Chris Muller -
Göran Krampe -
Milan Zimmermann