Nonsticky-session support: touching unmodified/not-updated sessions must be solved differently

[GoogleCodeExporter]

For sticky sessions there's an optimization that sessions are only updated in 
memcached if the session content has changed.
Such sessions are "touched" in memcached regularly (some time before they would 
expire), this makes use of tomcats background processing and the locally stored 
sessions.

For non-sticky sessions this does not work as there are simply no sessions 
stored locally, therefore this must be handled differently.

Original issue reported on code.google.com by martin.grotzke on 3 Jan 2011 at 12:50

• Blocking: #70

[GoogleCodeExporter]

Related:
- http://code.google.com/p/memcached/issues/detail?id=110
- http://groups.google.com/group/memcached/msg/6065589855271fcf

Original comment by martin.grotzke on 4 Jan 2011 at 9:14

[GoogleCodeExporter]

For each request it must also be provided that the lastModified timestamp is 
updated, e.g. it's saved under a separate key (which would have to be used for 
validation checking).

Original comment by martin.grotzke on 14 Jan 2011 at 7:51

[GoogleCodeExporter]

This is implemented now (in non-sticky branch).

One part of the solution is that session's maxInactiveInterval, 
lastAccessedTime and thisAccessedTime are stored separately in memcached. This 
information is updated in memcached for each request to know exact session 
validity information.

Additionally non-sticky sessions are stored in memcached using the double 
session timeout for expiration in memcached. It must be provided, that a 
session in memcached has no shorter expiration than session timeout, so a 
session is stored in memcached (even if it was not modified) if this 
requirement were not be fulfilled.

Original comment by martin.grotzke on 22 Jan 2011 at 8:42

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by martin.grotzke on 27 Jan 2011 at 10:36

• Added labels: Milestone-1.4.0