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 On Oct 31, 1:16 am, qyb <[EMAIL PROTECTED]> wrote: > No.1 Extend session module to support memcached. I think memcached > have been proven as a powerful technology to handle session data. > Session files couldn't fit distributed system and session db is > bottleneck in high-volume site. > > No.2 (The difference between cache and session data is, cache doesn't > need persistent, reliable storage. If fetching cache fail, it just > need get from orignal datasource again and store it in a temp area). > Serialize/Unserialize(Marshal and cPickle) are slow to my application, > so I think maybe we could cache some big, complex objects in webpy's > global space. Then it should supply some thread-safe fetch/store > methods and a internal GC mechanism to avoid memory issue --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
