

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

======
cratermoon
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.

------
facorreia
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](http://securesocial.ws/guide/configuration.html)

~~~
thirsteh
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."

~~~
facorreia
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.

