On Sun, Mar 02, 2008 at 01:31:42PM +0000, Ash Berlin wrote: > > On 2 Mar 2008, at 03:50, Jonathan Rockway wrote: > > >In the second case, it's just a bug in the Session::Store::Cache store > >that can be fixed with the addition of a backend_expires configuration > >key, probably set to "never" by default. > > Not quite true. It would look like it fixes it for most cases. A cache > is just a cache. Don't rely on them (particularly memcahced) to keep > data around until you told it you would like it to expire at - there > is no guarantee of this happening, especially under heavy load.
Yes, very true. A cache is a cache. And the database server could blow up, too. What we are talking about is a situation where the session data is (seemingly) suppose to persist for X seconds between requests, but it's instead persisting X seconds between updates to the session (which may not be every request). It appears from the design of the Session plugin that it's suppose to persist X seconds between requests (the "expires" entry). So, it looks like a design problem. The fact that you might be using a store that deletes entries for other reasons than expire time is another issue. -- Bill Moseley [EMAIL PROTECTED] _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
