in reply to Re: mod_perl and sessions
in thread mod_perl and sessions

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).

Replies are listed 'Best First'.
Re: Re: Re: mod_perl and sessions
by perrin (Chancellor) on Jun 11, 2003 at 22:12 UTC
    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).