I use ASP.NET and WCF services in a load balanced web server environment, using Memcached in the service layer.
I also wanted to replace the use of ASP.NET State Ser
In an ideal situation, the session data is only a single value, the internal numerical representation of the user id. It means that the user has passed the login page successfully with providing the correct password.
But what about others like, take stackoverflow for example, the dynamic data on the page depending on the user: the nickname of the user, the reputation number, the badges earned, the permssion to leave a comment. They are often the result of multiple JOINs across multiple database tables.
If you don't put memcached in use, these queries almost always read data from disk, which is a very slow, not very scalable operation. The cache inside the database? What do you think the hit ratio would be considering the database does things other than managing session data? Why do you have to read from disk while you can from memory?
Of course, any writes to the relevant user information should invalidate the corresponding session in memcached.
http://www.codeplex.com/memcachedproviders has a session state provider for asp.net that stores values in memcached. It provides the ability to backup the session data in ' SQL Server. As yogman said the session data is stored as one value. If an eviction happends, whole session for that user is lost and user will be directed to the login screen. Memcached doesn't evict any data before expiration unless it is running out of space to hold new data.
Memcached doesn't support data mirroring at present, it only provides the ability to split your entries across multiples servers to try to prevent one from getting swamped. This works by either hashing your key with the address of the server, or by using the consistent hashing algorithm (libketama).
In general though, Memcached should not be viewed as a persistent storage layer, and in almost all cases, the data in the cache should be the same as in the database. If you are making a change to a user's session data and want to cache it, update it in Memcached, then update it in the database immediately afterward. If you want to be really careful, you could implement a simple journalling system to make sure this data stays consistent in the case of a system failure.
Memcached is definitely being used for caching sessions though, the creator says as much in a Jinux Journal article. It is really only meant for optimizing read operations, at the end of the day, any data you care about should be stored in the database.