Sessions (PHP) and how they interact with each other

Question

This is a question about sessions in php.

I have Page A.php, C.php, D.php. A.php is displaying content A, upon login I want A.php to display content B, when moving from Page A.php to Page D.php and then again to A.php it displays the content A instead of content B.

The pages A.php C.php and D.php are all communicating through ajax.

I'm wondering how can I check if a session is on-going on page A.php with ajax, so that it displays content B instead of content A.

Answer 1

TL;DR;

You shouldn't.

Simply because your problem isn't the session it's a race-condition.

---

First, one needs to be clear about the distinction between an HTTP request and a PHP script. Each HTTP request can invoke multiple PHP scripts (e.g. one script includes another script in the same request). However, multiple HTTP requests to the same or different script always run in their own isolated environment (where no request shares information with another request). This is the share-nothing architecture that PHP is built on and it's important to understand this concept when dealing with PHP server-side sessions.

It's also important to recognize that each user typically has their own session file on the server. So concurrent requests from multiple users is normally not a problem no matter how many scripts are making use of that session in a single request.

The default session handler in PHP will lock an active session from the moment session_start() is called until the script ends or session_write_close() is called. This exclusive lock prevents any other instance of the interpreter from being able to read from or write to this session file until the lock has been released (in order to prevent corruption in the session). This means that concurrent requests to the same session will block. However, this is only a problem when the same session is being accessed from multiple concurrent HTTP requests (such as in the case of multiple asynchronous - AJAX - requests).

In other words, PHP makes it safe for you to transparently use the session across multiple concurrent requests without having to worry about the concurrency model breaking your session.

This, however, does not mean that you should rely on the session for the purposes of concurrency.

---

Let me give you an example of race conditions you can yourself design by accident. The user lands on your homepage at www.example.com where a session is started by A.php (and say the user is not logged in). Now, the user attempts to log in (say C.php is the script responsible for login/authentication and is called through AJAX). Let's say C.php redirects the user back to the homepage after login (typical PRG scenario). When A.php is loading again it's using the session and is locking it. Let's say another AJAX request is triggered in the background to B.php, which also needs the session. It will have to wait on A.php to release the lock or end before it can do anything. So now it's sitting in a blocked state until that lock is released.

Typically these kinds of issues don't matter if your requests are loading within a reasonable amount of time (typically just fractions of a second). They do however have cascading consequences.

Let's say your javascript has a setInterval() callback that calls on B.php every 5 seconds. Now let's say your server becomes suddenly overwhelmed with requests and B.php is now taking about ~6 seconds to load. Now your webserver has a queue backedup with multiple requests that will all block each other as they'll be all asking for the same session. You can see how this can become more and more of a problem if not planned for carefully.

---

Sessions are generally used as a way to keep stateful information through what is otherwise a stateless protocol (i.e. HTTP). This usually works out fine for tracking things like is the user authenticated/logged-in, preferences they may have saved on your site, or shopping cart checkout information, etc...

What you really shouldn't rely on the session for is tracking state beyond that which concerns a single request. Meaning, if you want to use a session to determine if the user is making other concurrent requests or examine other sessions outside of this user's immediate request you're really breaking some of the architecture constraints that PHP was designed around and are likely to run into unexpected failures.