On Sun, 2006-04-02 at 23:41 -0400, John (Versimedia) wrote: > Memcached is about 20% faster than using MySQL for session IDs.
Doing the wrong thing faster isn't much good though... > Yes, I understand this -- but that is not the concern I have -- my concern > is that the connections are not being closed when used in Mason/Apache for > some reason -- they are staying persistent. They are kept open for performance reasons. They should only close if the memcached server dies. > * I kill the memcached daemon and restart it -- at this point my valid > session ID stored in the cookie (for example "A1" no longer exists. > > * The next time I reload apache, the session ID should change to a new one, > for example B1 -- and each time I reload the page after that, it should stay > B1 since Apache::Session has now created and stored the new ID. > > However, this is not what is happening -- as I reload the page over and > over, the ID keeps changing on each load. Cache::Memcached notices when a server goes down, and removes that server from the pool of available ones. I don't think it notices when a dead server comes back up. You would have to tell it, probably by calling set_servers() on the Cache::Memcached object. I don't know if Apache::Session::Memcached makes that available or not. > Yes, but the Apache::Session::Memcached should be detecting the connectin to > the server failed so that it can report back to the system somehow -- > otherwise there is no way to know that the key being returned is really > invalid -- if it is not being stored somewhere (such as memcached or a > dbase), it is worthless(?) That's all intentional behavior of memcached. You are not supposed to care if it stores anything or not, since your application is supposed to be only using it to cache data that is really stored somewhere else. - Perrin ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Mason-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mason-users
