in reply to mod_perl and sessions

I've never used CGI::Session so I can't comment on it, but here's one thing you should think about: a session is not the right place to cache data! If you put, for example, someone's search results into her session so that you can display them 20 at a time, and then she opens a second browser window and does another search at the same time, all hell will break loose. It's better to cache data under some canonical name (e.g. string the search parameters together to form a unique ID) and store it with something like Cache::Cache.

Replies are listed 'Best First'.
Re: Re: mod_perl and sessions
by glwtta (Hermit) on Jun 11, 2003 at 22:07 UTC
    Good point, except that the "sessions" in this case are not necessarily tied to "user sessions" - a new session id would be generated for each search, and embedded in the URLs to retrieve the data (I would never store these "session" ids as cookies). In fact this also allows people to share the search sessions, simply by exchanging the formatted URLs.

    Would Cache::Cache offer any additional advantages with this scenario? The way I see it, CGI::Session will also generate the ids for me (and I can use the same mechanism for storing actual user sessions, should I need them).

    (Incidentally, a few popular systems use this concept of "session" as different from an HTTP session - Lion's SRS comes to mind; so my users are quite used to the idea).

      If you make sure to generate a new ID for every search then it should work. Personally, I would just use the combined search params as an ID, but it doesn't make much difference.

      Cache::Cache offers a concept of expiration, which I think CGI::Session does as well. Cache::Cache can handle multiple namespaces for caching different kinds of things, which could be an advantage. For example, you could set different expirations or clear out all the cached data from one section without touching the other cached stuff.

        I would just use the combined search params as an ID, but it doesn't make much difference.

        The search parameters are pretty much what I am trying to cache - I am not caching the actual search results just the query I would need to run (with the newly provided LIMIT and OFFSET); The running time for these queries is more than acceptable, but they are verbose enough that passing them around via query strings can quickly become unwieldy.

        Thanks for your help though, I'll definitely give Cache::Cache a look. One feature I really like that it seems to be missing is database backends (Postgres specifically).