Session handler using a PDO connection to read and write data.
It works with MySQL, PostgreSQL, Oracle, SQL Server and SQLite and implements different locking strategies to handle concurrent access to the same session. Locking is necessary to prevent loss of data due to race conditions and to keep the session data consistent between read() and write(). With locking, requests for the same session will wait until the other one finished writing. For this reason it's best practice to close a session as early as possible to improve concurrency. PHPs internal files session handler also implements locking.
Attention: Since SQLite does not support row level locks but locks the whole database, it means only one session can be accessed at a time. Even different sessions would wait for another to finish. So saving session in SQLite should only be considered for development or prototypes.
Session data is a binary string that can contain non-printable characters like the null byte. For this reason it must be saved in a binary column in the database like BLOB in MySQL. Saving it in a character column could corrupt the data. You can use createTable() to initialize a correctly defined table.
LOCK_NONE = 0
No locking is done. This means sessions are prone to loss of data due to race conditions of concurrent requests to the same session. The last session write will win in this case. It might be useful when you implement your own logic to deal with this like an optimistic approach.
LOCK_ADVISORY = 1
Creates an application-level lock on a session. The disadvantage is that the lock is not enforced by the database and thus other, unaware parts of the application could still concurrently modify the session. The advantage is it does not require a transaction.
This mode is not available for SQLite and not yet implemented for oci and sqlsrv.
LOCK_TRANSACTIONAL = 2
Issues a real row lock. Since it uses a transaction between opening and closing a session, you have to be careful when you use same database connection that you also use for your application logic. This mode is the default because it's the only reliable solution across DBMSs.
$pdo : \PDO|null
$dsn : string|false|null
DSN string or null for session.save_path or false when lazy connection disabled.
$driver : string|null
$table : string
$idCol : string
$dataCol : string
$lifetimeCol : string
$timeCol : string
$username : string
Username when lazy-connect.
$password : string
Password when lazy-connect.
$connectionOptions : array
Connection options when lazy-connect.
$lockMode : int
The strategy for locking, see constants.
$unlockStatements : \PDOStatement[]
It's an array to support multiple reads before closing which is manual, non-standard usage.
$sessionExpired : bool
True when the current session exists but expired according to session.gc_maxlifetime.
$inTransaction : bool
Whether a transaction is active.
$gcCalled : bool
Whether gc() has been called.
__construct(\PDO|string|null $pdoOrDsn = null, array $options = []) : mixed
You can either pass an existing database connection as PDO instance or pass a DSN string that will be used to lazy-connect to the database when the session is actually used. Furthermore it's possible to pass null which will then use the session.save_path ini setting as PDO DSN parameter.
List of available options:
| \PDO|string|null | $pdoOrDsn | A \PDO instance or DSN string or URL string or null |
| array | $options |
When PDO error mode is not PDO::ERRMODE_EXCEPTION
createTable() : mixed
Creates the table to store sessions which can be called once for setup.
Session ID is saved in a column of maximum length 128 because that is enough even for a 512 bit configured session.hash_function like Whirlpool. Session data is saved in a BLOB. One could also use a shorter inlined varbinary column if one was sure the data fits into it.
When the table already exists
When an unsupported PDO driver is used
doRead(string $sessionId) : string
Reads the session data in respect to the different locking strategies.
We need to make sure we do not return session data that is already considered garbage according to the session.gc_maxlifetime setting because gc() is called after read() and only sometimes.
| string | $sessionId |
beginTransaction() : void
Helper method to begin a transaction.
Since SQLite does not support row level locks, we have to acquire a reserved lock on the database immediately. Because of https://bugs.php.net/42766 we have to create such a transaction manually which also means we cannot use PDO::commit or PDO::rollback or PDO::inTransaction for SQLite.
Also MySQLs default isolation, REPEATABLE READ, causes deadlock for different sessions due to https://percona.com/blog/2013/12/12/one-more-innodb-gap-lock-to-avoid/ . So we change it to READ COMMITTED.
doAdvisoryLock(string $sessionId) : \PDOStatement
Executes an application-level lock on the database.
| string | $sessionId |
When an unsupported PDO driver is used
The statement that needs to be executed later to release the lock
getMergeStatement(string $sessionId, string $data, int $maxlifetime) : ?\PDOStatement
Returns a merge/upsert (i.e. insert or update) statement when supported by the database for writing session data.
| string | $sessionId | |
| string | $data | |
| int | $maxlifetime |