> 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
In MySQL you can create individual tables in memory: CREATE TABLE t (i INT) ENGINE = MEMORY; Additionally, in webpy .30 there will be multiple database support. Regarding the cached session data, it sounds like you know what you're doing. I'd recommend trying to keep it simple -- that is, I wouldn't implement garbage collection until you're sure it'll be a problem (no need for premature optimization when you can avoid it). If you're looking for some examples with that, you may want to check out the memoize function decorator within webpy. It's a very simple caching utility that I've found handier than writing one myself :-) Good luck, Justin On Nov 1, 12:36 am, qyb <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
