A mysql server with memory-db-engine may resolve my No.1 requirement. But I remember webpy's session implement limit that session db must be the same db of main app, so that a session-memcached is still useful.
About my No.2 requirement, please notice my description of the difference of "Session" and "CACHE", Session data are small, access frequently(exactly access with every url request) and couldn't be drop until we sure user logoff from the app. And cache are complex objects. we use cache for accelerating some slow read-operation. My app's cache data are so big and complex that serializing and saving them in db/ file/memcached is unacceptable. If webpy app is killed via fastcgi and lost all "cache" in its memory space, that isn't disaster, restarting it and rebuilding cache is ok. J2EE's container provide a way to store any objects in memory for it's application. I wish webpy could do the same thing. Sorry for my poor english.. :) On 11月1日, 上午8时55分, Justin Davis <[EMAIL PROTECTED]> wrote: > This is only sort of answering your question, but I'll add my 2 cents > anyway :-) > > The problem with storing things in memory is that people using fastcgi > (a good percentage I believe) have issues. Fastcgi can pretty much > kill a process whenever, so it can't just keep things in memory. > > That being said, you should be able to create a database table in > memory (I know MySQL and SQLite have this feature, and I'd imagine > Postgres has it too), and use that. That way, the processes can be > killed via fastcgi, but the session data will remain in the continuous > database process. > > Cheers, > Justin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web.py" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/webpy?hl=en -~----------~----~----~----~------~----~------~--~---
