What kind of DB system are you running? Our DB has been up/running for the past 3 years, 8 months, 4 days and assorted hours. We took it down to upgrade the hardware and DB from SQL Server 2005 to SQL Server 2008R2. It runs in a cluster and we have planned failovers for maintenance, but the database is still up/available. Our web/app serevers are hardly that robust and restart, on average, once a week. Maybe you're solving the wrong problem, I'd fix the DB availability issue first. I do agree that session state shouldn't be stored in an RDBMS, I have seen some fairly slick key-value implementations using noSQL as well as a couple of state server implementaitons that scale quite well. IMHO: you have to use the right tool for the job. BTW: ORMs kill DB performance. Most of the code generated by an ORM where more than one table is involved absolutely suck. If the issue with ORM's ever gets fixed then I may be persuaded, but that day isn't here, yet.
What kind of DB system are you running? Our DB has been up/running for the past 3 years, 8 months, 4 days and assorted hours. We took it down to upgrade the hardware and DB from SQL Server 2005 to SQL Server 2008R2. It runs in a cluster and we have planned failovers for maintenance, but the database is still up/available. Our web/app serevers are hardly that robust and restart, on average, once a week. Maybe you're solving the wrong problem, I'd fix the DB availability issue first. I do agree that session state shouldn't be stored in an RDBMS, I have seen some fairly slick key-value implementations using noSQL as well as a couple of state server implementaitons that scale quite well. IMHO: you have to use the right tool for the job. BTW: ORMs kill DB performance. Most of the code generated by an ORM where more than one table is involved absolutely suck. If the issue with ORM's ever gets fixed then I may be persuaded, but that day isn't here, yet.