Hi Justin,
Thanks for your input. (thanks to the others also but Justin has some direct
questions which I'm attempting to answer).
RE:
using a database is the most common way to solve this.
That seems to be the message I'm getting. I am in a position to write my own session handler, and this is something that I have
considered, but rather than rush in and re-invent the wheel thought I'd do some research first.
But I do feel at this point that using the database to hold the session is the best idea. In order to achieve redundancy in the
future, one has to fix the database replication problem in any case, so putting the session in the database doesn't add to the
complexity of that problem. Putting the session information on the web / application server however does. I accept that PHP
sessions have their place, but in a large 24 x7 environment it immediately ties the user to a specific server. Solutions that then
attempt to fix that by getting into the network layer and sending the user back to the same server or copying the session
information between web servers are just patching up on an initial bad technology decision. Better to just add it to the database
issue and then figure out how to replicate the database which is a problem I have to solve in the long term anyway.
this is a bit unclear to me. do you want real sync between multiple
dbs, so the data is always consistent or just fail-over?
I have installed and configured an Oracle system in the past that had multiple web servers fronting dual database servers that
where configured as multimaster with two phase commit etc and know that it can work but also understand the "pain" in that
equation. This is for the future though and may never happen, depends on how successful the site is.
can you give us any more general info about the setup?
Well it's your classic LAMP web site right down to the part of using PHPS's Mysql specific database functions embedded within the
pages that contain the Html. This is something that I'm slowly fixing by removing all the sql code from the html pages and placing
it into data classes. I'm also abstracting the sql functions so that I can get adodb in there and thus use prepared statements, or
change to Postgresql, Oracle (insert latest favorite rdbms here).
However this is not something that I have to fix right away, it's a decision about which direction to head in. If all goes well
the site "may" grow to be more than what can be handled by one server but also it's a 24x7 environment and scheduled outages to
upgrade hardware / software etc, won't be an acceptable outcome. Unscheduled outages would also be bad, but one does live in the
real world and servers do crash. However failing to plan for hardware/software infrastructure futures is not showing due
diligence. With "cloud" computing, virutalisation, snap shots and fail overs, the options for redundancy and fail over are much
greater these days. So I'm at the "researching the options" stage. No plans to move away from Linux though ;-)
Cheers
Pete
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
