Why you should not “store” your sessions in memcached

http://bearmountain.io/why-you-should-not-store-your-sessions-in-memcached

by varsketiz • 12 years ago

4 4 12 years ago

facorreia2• 12 years ago

It amazes me how widespread is the notion that a cache can be used to "store" things. Case in point:

"SecureSocial uses the Play cache to store values while signing in users via OAuth. If you have more than one server then make sure to use a distributed cache (eg: memcached)." [1]

[1] http://securesocial.ws/guide/configuration.html

thirsteh• 12 years ago

It's widespread because they can be used to store values (ephemerally.) For things like session tokens that need to be accessed quickly and often, but change rarely, using a cache (e.g. in front of an RDBMS) is often a decent choice.

What amazes me is that the best argument against using a cache is "your cache server might run out of memory."

facorreia2• 12 years ago

When stored only in memory, the sessions can be evicted at any time for any number of reasons, from eviction to node failure. This would lead to data loss (in this case, session data). Using a cache on top of a permanent data store is the traditional way to use it, for accelerating access, but without risking data loss in case the cache is lost.

cratermoon• 12 years ago

It really depends on the use case for the sessions and expectations. At some point the user's session will, and SHOULD, timeout anyway. Proper sizing and configuration of memcache and resilient interfaces will reduce the chance of random session loss.

Of the four bullet points at the start of the article, three of them apply equally to many or all RDBMS-backed stores.

Resource limitations, upgrades, and infrastructure changes can negatively affect RDBMS-backed services just as well.

Why you should not “store” your sessions in memcached

Related Stories