Installation guide

Read via session_start()
(Using
PessimisticLockingStrategy)
• A minimum of 1 write operation.
• (Conditional) Additional write operations for each attempt at
acquiring a lock on the session. Based on configured lock wait time
and retry options.
• (Conditional) 1 write operation to delete the session if it is expired.
Write via
session_write_close()
• 1 write operation.
Delete via session_destroy()
• 1 write operation.
Garbage Collection
• 0.5 read operations per KB of data in the table to scan for expired
sessions.
• 1 write operation per expired item to delete it.
Session Locking
The DynamoDB Session Handler supports pessimistic session locking in order to mimic the behavior of PHP's
default session handler. By default the DynamoDB Session Handler has this feature turned off since it can become
a performance bottleneck and drive up costs, especially when an application accesses the session when using ajax
requests or iframes. You should carefully consider whether or not your application requires session locking or not
before enabling it.
By default the session handler uses the NullLockingStrategy which does not do any session locking. To
enable session locking, you should use the PessimisticLockingStrategy, which can be specified when the
session handler is created.
$sessionHandler = $dynamoDb->registerSessionHandler(array(
'table_name' => 'sessions',
'locking_strategy' => 'pessimistic',
));
Garbage Collection
The DynamoDB Session Handler supports session garbage collection by using a series of Scan and
BatchWriteItem operations. Due to the nature of how the Scan operation works and in order to find all of the
expired sessions and delete them, the garbage collection process can require a lot of provisioned throughput.
For this reason it is discouraged to rely on the PHP's normal session garbage collection triggers (i.e., the
session.gc_probability and session.gc_divisor ini settings). A better practice is to set
session.gc_probability to 0 and schedule the garbage collection to occur during an off-peak time where a
burst of consumed throughput will not disrupt the rest of the application.
For example, you could have a nightly cron job trigger a script to run the garbage collection. This script might look
something like the following:
require 'vendor/autoload.php';
use Aws\DynamoDb\DynamoDbClient;
use Aws\DynamoDb\Session\SessionHandler;
$dynamoDb = DynamoDbClient::factory(array(
'key' => '<aws access key>',
'secret' => '<aws secret key>',
'region' => '<region name>',
));
$sessionHandler = SessionHandler::factory(array(
'dynamodb_client' => $dynamoDb,
'table_name' => 'sessions',
DynamoDB Session Handler
130