While the previous poster has a point that Memcached can and will cleanup to make room for it's keys, the likelihood of active sessions (due to the likelihood that they will be written to again within 30 seconds) is fairly low provided you have your memory allocation properly alloted.
セッションのサポート
Memcached は独自のセッションハンドラを用意しており、 これを使用するとユーザーセッションを memcache に格納することができます。 内部的に使用するのは完全に分離された memcached インスタンスなので、 必要に応じて別のサーバープールを使用することができます。 セッションのキーは、プレフィックス memc.sess.key. をつけて格納されます。 同じサーバープールでセッションと一般のキャッシュを両方使用する場合は注意しましょう。
sstratton at php dot net
14-Jun-2011 10:18
Tobias
17-Feb-2011 06:05
You probably don't want to use Memcache, Memcached or anything else similar for storing sessions (in RAM via memcached daemon server), because those sessions can easily be thrown away/discarded, become unreachable for various reasons, and then your user gets logged out without warning.
What memcache is great for, in general, is storing the results of an SQL or MongoDB query, using the md5() has of the query itself as the key lookup.
For example, for all database queries, get the md5() hash of the query, then look for that key in memcache. If it's found, great, grab the results, check they're not too old / outdated, and use them if okay. Otherwise, pass through the query to underlying storage-based DB, then save its results into memcache before passing them back to your app.
This general applicability of how, when, where and why to use memcache to greatest advantage and least pain isn't so easy to find on the web.
Memcached module is great for new features, etc. (except now it's almost one year since update) but it's difficult to tell when a memcached daemon goes away, crashes, becomes unreachable.
Memcache at least has ->connect() method which will report failure/unreachability, but its features are behind.
These two projects are moving targets, competing, and it would be nice to get both together, so we can all benefit from best efforts. Meanwhile, what a mess, and what a charm!
nfoo at naver dot com
28-Aug-2010 09:45
If you want to use 'memcacheD' extention not 'memcache' (there are two diffrent extentions) for session control, you should pay attention to modify php.ini
Most web resource from google is based on memcache because It's earlier version than memcacheD. They will say as following
session.save_handler = memcache
session.save_path = "tcp://localhost:11211"
But it's not valid when it comes to memcacheD
you should modify php.ini like that
session.save_handler = memcached
session.save_path = "localhost:11211"
Look, there is no protocol indentifier
Andrei Darashenka
27-May-2009 05:26
This extension supports Session-locking!
by default
MEMC_SESS_LOCK_ATTEMPTS 30
MEMC_SESS_LOCK_WAIT 100000
MEMC_SESS_LOCK_EXPIRATION 30
