>> The example is a very active web site, the flow is this: >> >> query for session information >> process HTTP request >> update session information >> >> This happens for EVERY http request. Chances are that you won't have >> concurrent requests for the same row, but you may have well over 100 >> HTTP >> server processes/threads answering queries in your web server farm. > > You're crazy :) Use memcache, not the DB :) >
I actually have what I consider a better and more complete session handler system. MCache formally MSession. (http://www.mohawksoft.org/?q=node/8) I mean, it implements a LOT of nifty features, loadable function modules, collision safe counters and operators, ability to save session data to file or SQL database and at varying levels of caching, but that doesn't mean it is used. Technologies like memcached and my mcache are a separate data store. Your session data is not usable anywhere but in your web system. I have gone as far as to write a session serializer for PHP that outputs XML, a PostgreSQL plugin that can extract data from the XML session string, and a set of functions for interfacing mcache with PostgreSQL and I still have a hard time convincing clients that this is the right way to go. While we all know session data is, at best, ephemeral, people still want some sort of persistence, thus, you need a database. For mcache I have a couple plugins that have a wide range of opitions, from read/write at startup and shut down, to full write through cache to a database. In general, my clients don't want this, they want the database to store their data. When you try to explain to them that a database may not be the right place to store this data, they ask why, sadly they have little hope of understanding the nuances and remain unconvinced. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
