----- Original Message -----
From: "Perrin Harkins" <[EMAIL PROTECTED]>
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, but you are assuming what I am doing is wrong...
Most caching will be just to store non-critical data, like how many page
visits a visitor has had, or what pages they came from etc. -- for
statistical purposes. I also may store user login session data, however
this will be backed up in a user DB anyway, and if memcached goes down and
back up I can reload this information from the user table -- it is not lost.
(In a sense I am using memcached as a cache on dbase stored session data).
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.
Ok, that is understood and fine. I did not know if it mattered how I used
it. Dbase connections do not stay open unless you use tools to have them
stay that way, so I wondered if there was some option I was missing.
* 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.
As of this time, it does not seem A:S:M passes on the fact that there is no
memcached server available... which seems like a flaw. (see below for more
details)
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.
I understand that about memcached -- however if that is the case, then it
seems A:S:M is unusable. If you cannot rely on at least knowing that
memcached is not working, then you cannot store session data. Am I wrong on
this?
Maybe the flaw is that A:S:M should work like the standard memcached
model -- it should check for session data in the memcached dbase, and if it
is not there, check the dbase for it...
I started a thread over on the memcached mailing list to see what they have
to say there.
-John
-------------------------------------------------------
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
