"stuart 'zen' bishop" <ze-@cs.rmit.edu.au> wrote:
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
Thanks for everyone that replied. Scalability is very important to me. I have to keep in mind eventual load balancing: using more than one Zope webserver. So the session data must be accessible from many Zope servers. This makes the current FSSession and Gadfly-based SQLSession unsuitable. Current FSSession and SQLSession are all designed for single-server configuration. I could use SQLSession with another database, (including an independent Gadfly), with some optimization like keeping things in RAM during a transaction. Cron job or explicit cleaning will be needed to clean up the session_data table, if computer crashes. For the immediate short term, I guess I'll use this approach. RAM session clears the session_data automatically when the computer crashes. :) Performance is faster, reliability is about the same as an SQLSession. It's easy to scale up. When hackers attack, it's probably better to have junk filling up my RAM than junk filling up my disk/database. One drawback is it gets expensive when you have too many users... but that's probably OK. Hung Jung ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com