If availability is more important than persistence, memcached is exactly the right solution.
What we do in one of our projects is that when a session starts, we put a session object in memcached for that user. On each pageview for that user, we then fetch the session object from memcached, update it, and set it back. We also update the DB, but no more often than every 60 seconds, since persistence is nice, but not critical. When a session ends, we remove the session object from memcached (it also has an expiry time of 15 minutes), and that's about it. As an added bonus, given a range of userids, we can answer the question "which of these users are online?" simply by doing a multi-get to memcached and see who has a session object and who hasn't. And again, why do you want to save the session info in more than one place? Why is that important? You said it yourself that availability is more important than persistence? /Henrik On Tue, Jun 30, 2009 at 22:27, Tzury Bar Yochay <[email protected]>wrote: > > > If persistence is important, that is the right approach. We use > > memcache for sessions at dealnews, but they are not ecommerce related or > > mission critical information. It's not worth the DB write for us. > > High availability is the most important thing for us. Not persistence. > If memcached is not the solution can anyone point out about other > possible solutions? > What would be the best way to have a session saved in more than one > server? >
