On Thu, Mar 18, 2010 at 6:49 PM, dormando <[email protected]> wrote: > I had a thought; You could use ADD to "ping" the sessions every time > they're accessed. When a session is served from local memory, do an async > ADD of a 0 byte value with a 1 second expiration time against that > session. If the add command fails it actually promotes the existing item > to the head of the LRU. If it doesn't fail you probably want to SET the > session back into memcached. Cool! I wasn't aware of this ADD semantics...
> Feels like your background thread is a little wrong as well. If you can > journal in the session somewhere the last time it was written to > memcached, your thread could update purely based on that. ie; if they're > off by 5+ minutes, sync them asap. So then: > > - session created, 1hr expiration. session notes it is "clean" with > memcached as of that second. > > - session accessed 10 minutes later, not modified. 1hr expiration, 50 mins > in memcached. Session is pinged via ADD and moves to head of LRU. Fresh. > > - 5 minutes later, background thread trawls through sessions in local > memory whose "memcached clean" timestamp is 5+ minutes off from its last > accessed time. syncs to memcached, updates session locally to note when it > was synced? Session is still relatively "fresh" (last accessed 10 minutes > ago). Bumping it to the top of the LRU isn't as bad of a problem as > bumping a 50 minute old session to the top for no reason. > > - 55 minutes later, session expires from tomcat. Thread issues DELETE > against memcached which cleans up the session, if it's still there. Sounds like a good solution for the potential issue, and adding the "clean" timestamp is no issue. Thanx && cheers, Martin To unsubscribe from this group, send email to memcached+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
