[squeak-dev] Magma and shared sessions.

Sebastian Sastre ssastre at seaswork.com
Thu Mar 27 15:42:57 UTC 2008


Hi Bert,

	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

	???

	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: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] 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.
> 




More information about the Squeak-dev mailing list