[squeak-dev] Magma and shared sessions.
Locked
[squeak-dev] Magma and shared sessions.
 
|
So I'm building an application that's composed of two parts:
1. A Magma-backed Seaside web application. 2. A custom TCP/IP protocol server which accesses the same Magma database as the web application. Now, as of right now I have an extremely simple Seaside app built that is backed by Magma (using an MaSharedSessionAuto session object) and works well enough. Meanwhile, I've completed the first cut of the TCP server by subclassing TcpService and going from there. But I'm unclear on how to properly access the database from the TcpService (since both the Seaside app and the service need share a single database). My first approach was to instantiate a new MaSharedSessionAuto instance inside my service class for each call to serve:. Unfortunately, instantiating a session instance and connecting to the database appears to take a non-trivial amount of time, so that proved untenable. My second, and current, approach is to instantiate a single MaSharedSessionAuto instance when the service is first initialized. Then, each call to serve: makes use of the same session instance. So, fundamentally, I guess I'm wondering if this the right way to do things. Each call to serve: is handled in a separate Process, and I'm unclear if it's safe to access an MaSharedSessionAuto instance from multiple threads (I'm assuming Seaside handles things a little differently, since sessions are long-lived things in that world, unlike my TCP service, which deals with short, sporadic, independant request/response pairs). Furthermore, do I have to do anything special to ensure consistency between the TCP service and the Seaside application? Brett. |
RE: [squeak-dev] Magma and shared sessions.
|
|
Hi Bert,
I dont think I get what are you trying to do in the way you talk about. Maybe you just need: 1. A seaside application whith Magma ODB reachability 2. Another image in another host (or even same host) with reachability to the same ODB ??? If so you only need to setup a magma server in one of those images and in both you can use magma clients (by using MagmaSession) to access the same ODB. For sharing efficiently you can use (in both images) a pool of magma sessions. You can see an example of it in Gjallar sources (http://www.gjallar.se/) cheers, Sebastian Sastre > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En > nombre de Brett Kosinski > Enviado el: Jueves, 27 de Marzo de 2008 10:32 > Para: The general-purpose Squeak developers list > Asunto: [squeak-dev] Magma and shared sessions. > > So I'm building an application that's composed of two parts: > > 1. A Magma-backed Seaside web application. > 2. A custom TCP/IP protocol server which accesses the same Magma > database as the web application. > > Now, as of right now I have an extremely simple Seaside app built that > is backed by Magma (using an MaSharedSessionAuto session object) and > works well enough. Meanwhile, I've completed the first cut of the TCP > server by subclassing TcpService and going from there. But I'm > unclear on how to properly access the database from the TcpService > (since both the Seaside app and the service need share a single > database). > > My first approach was to instantiate a new MaSharedSessionAuto > instance inside my service class for each call to serve:. > Unfortunately, instantiating a session instance and connecting to the > database appears to take a non-trivial amount of time, so that proved > untenable. > > My second, and current, approach is to instantiate a single > MaSharedSessionAuto instance when the service is first initialized. > Then, each call to serve: makes use of the same session instance. > > So, fundamentally, I guess I'm wondering if this the right way to do > things. Each call to serve: is handled in a separate Process, and I'm > unclear if it's safe to access an MaSharedSessionAuto instance from > multiple threads (I'm assuming Seaside handles things a little > differently, since sessions are long-lived things in that world, > unlike my TCP service, which deals with short, sporadic, independant > request/response pairs). Furthermore, do I have to do anything > special to ensure consistency between the TCP service and the Seaside > application? > > Brett. > |
Re: [squeak-dev] Magma and shared sessions.
|
|
> Hi Bert,
Brett ;) > I don't think I get what are you trying to do in the way you talk about. > > Maybe you just need: > > 1. A seaside application whith Magma ODB reachability > 2. Another image in another host (or even same host) with reachability > to the same ODB Yes, that's certainly one option. But why two images? Is there a reason I can't achieve the same with a single image (I'd prefer to have all the software related to this project stored in a single image... it makes things much easier for me to manage). Or is there something inherent in Magma that makes this arrangement unreasonable? Brett. |
RE: [squeak-dev] Magma and shared sessions.
|
|
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). 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? cheers, Sebastian Sastre > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En > nombre de Brett Kosinski > Enviado el: Jueves, 27 de Marzo de 2008 13:53 > Para: The general-purpose Squeak developers list > Asunto: Re: [squeak-dev] Magma and shared sessions. > > > Hi Bert, > > Brett ;) > > > I don't think I get what are you trying to do in > the way you talk about. > > > > Maybe you just need: > > > > 1. A seaside application whith Magma ODB reachability > > 2. Another image in another host (or even same > host) with reachability > > to the same ODB > > Yes, that's certainly one option. But why two images? Is there a > reason I can't achieve the same with a single image (I'd prefer to > have all the software related to this project stored in a single > image... it makes things much easier for me to manage). Or is there > something inherent in Magma that makes this arrangement unreasonable? > > Brett. > |
Re: [squeak-dev] Magma and shared sessions.
|
|
> 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. Brett. |
RE: [squeak-dev] Magma and shared sessions.
|
|
>
> 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). > The Seaside sessions or the MagmaSessions? Anyway: For Seaside sessions you dont manage them, Seaside does it for you. It's just about a few *concurrent* seaside sessions per image will make the image to work more reliably (memory stable and such). In case you need more than a few users concurrently, you use N images with the same application balanced with an apache. For MagmaSessions you should use a session pool as I already said to you cheers, Sebastian |
Re: [squeak-dev] Magma and shared sessions.
|
|
> For Seaside sessions you don't manage them, Seaside does it for you.
> It's just about a few *concurrent* seaside sessions per image will make the > image to work more reliably (memory stable and such). In case you need more than > a few users concurrently, you use N images with the same application balanced > with an apache. I suspect I'll be dealing with, at most, tens of users at a time (and I'm betting I can use a fairly short timeout period for the sessions, as well... maybe 10-15 minutes, probably). And I'm not terribly interested in load-balancing, so if Squeak/Seaside can't cut it, I'll just use a different framework. :) > For MagmaSessions you should use a session pool as I already said to you Sounds good, implementing a simplistic session pool should be trivial enough. Brett. |
RE: [squeak-dev] Magma and shared sessions.
|
|
>
> I suspect I'll be dealing with, at most, tens of users at a time (and > I'm betting I can use a fairly short timeout period for the sessions, > as well... maybe 10-15 minutes, probably). And I'm not terribly > interested in load-balancing, so if Squeak/Seaside can't cut it, I'll > just use a different framework. :) > You better ask for more opinions in the Seaside list. Seaside is available not only in Squeak (where that metric works fine for a conservative architecture). Cheers, Sebastian |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |