[dev] Process for session creation?
Kevin M. Myer
kevin_myer at iu13.org
Sat Oct 15 20:37:07 PDT 2005
Quoting Chuck Hagenbuch <chuck at horde.org>:
> No. First of all, what you describe would only happen if a session was
> opened/closed multiple times on the same page. $_connected does not
> persist across requests, just like any other PHP variable. Second, even
> in that case, the _pconnect functions don't open a "new connection" if
> there's already a persistent one - they return the existing persistent
> connection. That's the whole way persistent connections work.
Ok, I think I see the error in my assumptions. Resources persist,
variables do
not (unless they are stored in a session somewhere). That explains why I was
seeing new connection attempts for every session access, since I was testing
with configs that represented a down server and an available server.
I was originally planning to store information about the state of each of the
memcached servers (up or down), to avoid having to create any extra overhead
with connection setup/teardown, but if using persistent connections, this
shouldn't be that much of an issue. I still have a problem though, in that if
a server goes down, I need a way to flag it as down for anything calling the
sessionhandler, so that when it comes back online, any data on it will be
flushed, because its potentially stale. But thinking through that whole
process, the hash function for server selection will accomodate a down server
fine, and shift sessionid storage accordingly, but if the next action of the
sessionhandler is a read, and the server never had that sessionid stored
before, that read will fail. If its a write, things will be fine. So maybe
the idea that Didi suggested is the way to go - write to all servers and read
from a random one. But that breaks down if the servers have different memory
sizes.. Guess this is trickier than I originally thought it might be.
Kevin
--
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13 http://www.iu13.org
More information about the dev
mailing list