Hi, Has anyone done RAM session management? (storing session information in RAM.) I am thinking in implementing RAM session management. The picture I have is: (1) Implementing a mini TCP/IP server at a port in an internal server machine. Most likely I'll use Python. (2) The web server then talks to the session server via TCP/IP. Does this scheme seem OK? (Security, performance, scalabilty, etc.) regards, Hung Jung ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
----- Original Message ----- From: Hung Jung Lu <hungjunglu@hotmail.com>
I am thinking in implementing RAM session management. The picture I have is:
(1) Implementing a mini TCP/IP server at a port in an internal server machine. Most likely I'll use Python.
(2) The web server then talks to the session server via TCP/IP.
Does this scheme seem OK? (Security, performance, scalabilty, etc.)
It sounds like you'll be creating a lightweight alternative to SQL Session management. Consider for a moment that you might be able to get the benefits you're looking for *and* SQL compatibility by just using Gadfly on the remote machine. Gadly runs completely in-memory, is written in Python, etc. If you go that way, you'll probably want to get the latest from http://www.chordate.com rather than the one that comes with Zope. Cheers, Evan @ digicool
On Wed, 16 Feb 2000, Evan Simpson wrote:
----- Original Message ----- From: Hung Jung Lu <hungjunglu@hotmail.com>
I am thinking in implementing RAM session management. The picture I have is:
(1) Implementing a mini TCP/IP server at a port in an internal server machine. Most likely I'll use Python.
(2) The web server then talks to the session server via TCP/IP.
Does this scheme seem OK? (Security, performance, scalabilty, etc.)
You could also consider metakit, which is now open source. It would be nice to wrap it in Zope and I believe has an option of creating views in memory with no associate disk storage. I *really* want to find some time to wrap metakit in Zope but it won't happen for a while. Alternatively you can save the data in a dict object attached to some persistent object. If you access that dict object through its methods then nothing is going to be registered with the transaction manager, but as that object is going to be referenced frequently then it will stay in memory. This is essentially how FSSession works, but the in memory part lasts only for the period of a transaction. Pavlos
On Wed, 16 Feb 2000, Hung Jung Lu wrote:
Has anyone done RAM session management? (storing session information in RAM.)
I am thinking in implementing RAM session management. The picture I have is:
(1) Implementing a mini TCP/IP server at a port in an internal server machine. Most likely I'll use Python.
(2) The web server then talks to the session server via TCP/IP.
Does this scheme seem OK? (Security, performance, scalabilty, etc.)
This is probably overkill. It is quite possible to store the information in a package global dictionary/class/datastructure of a standard Zope product - just make sure you use locking on it where appropriate so it is thread safe. This allows you to share information between the Zope threads (but won't work for ZEO instances). If you take this approach, it could be trivially implemented by subclassing or hacking the FSSession product. One thing to dwell on - if you use the FSSession product, it will store the session information on the local file system. Although peoples first impression is that this will reduce performance, remember that the memory saved can be used by your OS for disk caching. Of course, if you want Session access for a CDROM Zope distribution it won't help you much :-) -- ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen
participants (4)
-
Evan Simpson -
Hung Jung Lu -
Pavlos Christoforou -
Stuart 'Zen' Bishop