PHP Session Storage

This is a continuation of my older article PHP Memcache Extension - Lesser Known Pitfalls. Reader Tony pointed out a very strong statement I made regarding not to use memcache as PHP session storage.
I have to admit that was some strong statements I made when I was writing that post. Thank you Tony for pointing that out. :) I have since changed the wording a bit to not deny the all usages of memcache in replacement of session.

Here's a couple situations I think are not good ideas when using memcache as the primary session storage:

1. putting shopping cart data in memcache on a high volume e-commerce site. if the memory on the memcache server runs out or it crashes, your customers will instantly loose everything in the cart.
2. putting user session data in memcache. this one is arguable. again, in a high volume situation, if memcache server goes away, just imagine how many queries will be triggered on your database.

I'm sure it's very arguable that none of those will be problems when using clustered memcache servers and have memcache servers installed with 64GB of memories (God forbid if all 64GB of data all got lost because of a power outage)

However, if the size of each session is controllable, growth of session data is foreseeable, and in case of failure, data is recoverable without triggering major disaster, I'm definitely pro on using memcache as the session storage. There are many ways to achieve this. Here's a couple ideas of mine:

1. Controlling the size of each session can be easily achieved by optimizing your code. A lot of times I see people toss everything into a session (like user data) just in case a piece a data might be needed somewhere, sometime in the future. This leads to a lot of unnecessary data being stored in session. 
2. Optimize the query that gets the data before it is set into session. In case of failure, you need to ensure that your database can handle the amount of traffic for recovering the data. If each lost session requires a major join query, you can well guess how long the database will last.
3. Have a backup plan for the session data. If you have the luxury of using data storage mounts backed by NAS, utilize it. Put your session data in memcache for fast access, leave a copy on the NAS for faster and safer recovery. (remember, I don't mean leave a copy permanently)
4. Again, if you have the luxury of using storage mounts backed by NAS, try use SQLLite for your user data. Each user will have his/her own SQLLite file. Whenever data needs to be retrieved, SQLLite file gets hit first. Imagine the load gets spread across thousands of disks. 

All in all, I'm not opposed to any form of session storages as long as all sides of it are well thought out and planned out.