I have the run-of-the-mill login-based PHPSESSID mechanism implemented for my web app. One aspect that bothers me is the simple scenario where a user orphans his session in browser A (on computer A), opens another in browser B (on computer B), orphans this to walk back to browser A and so forth. Possibly all this within the (reasonably lengthy) time span for which the PHPSESSID cookies are valid. If both sessions display the user static data, and the user is manipulating this, then the two browsers will not necessarily show data that is consistent with what's in the database. 

My preferred response to this scenario is for the second login two invalidate the first. I can keep one PHPSESSID associated with the userID in the database. That's easy enough. Now the hard part: on the second login, how can I invalidate the PHPSESSID that's written into the database such that a subsequent access from the first sessions (with the now invalidated PHPSESSID) will fail? 

(I cannot use session\_destroy() because that wants to kill the second PHPSESSID, the one I actually want to keep. And I cannot use setCookie() for exactly the same reason.)

One idea I had involves a database access sequence number. Each new request returns the previous plus one. If out of sequence, session\_destroy() the current enquirer. Slight inconvenience I see with this is that it requires an extra database fetch to recover the sequence number before each user access.

Is there any way of associating this sequence number with a userID somewhere inside the server's cache that doesn't involve any cookie transmissions?

Thanks.