I wrote about this last year, but it bears repeating. Database backed sessions in PHP will eat your data under normal circumstances.* (If your normal usage involves Ajax calls).
I'm going to explain this very plainly. PHP's session_set_save_handler() requires a locking strategy to avoid losing your data.
The callbacks registered with session_set_save_handler() are designed to work over the entire lifetime of the request. You read data at the beginning of the request, manipulate it over the lifetime of the request, and save it at the end (usually after the client closes the connection).
Obtaining file locks or database transactions should force concurrent requests to serialize themselves - one request waits for the previous to finish (a.k.a. release the lock). If you are skipping file or database locking (transactions) then you are foregoing the implicit serialization forced onto concurrent requests which are waiting to obtain a lock.
If you are making heavy use of Ajax calls (concurrent calls) and modifying session data in session calls, you can be sure that some session data will be lost unless you are using a locking mechanism. The default for file based sessions is to use a file lock generated by the OS.
If you are using some kind of database backed sessions, your locking mechanism has to be transactions (hopefully with row locking and not table locking). If you are using MySQL you cannot have nested transactions. So, starting one at the beginning of the request and closing it at the end prevents you from using any transactions for any other SQL statements.
There's no PDO way to abstract nested transactions, so it's likely that even if you're using PostgreSQL you'll still face the same problems.
The take away? Know your failure modes. Know what's happening with your data so you can make informed decisions.
Have you seen a proper DB backed session implementation? Let me know.