memcached_sessions.md

Memcached sessions

Requirements:

• Locking framwork (MDL-25500)

Goal

Being able to store session data in memcached.

Requirements

The simple use of memcached as a session handler is not enough. We need to have a framework that supports at least the same functionalities than the current database session framework in Moodle.

Locking of session

Require to ensure the consistency of the data. The session data cannot be accessed from an opened session while another request is pending.

Handling timeout in PHP

The authentication plugins can decide to cancel the timeout, we cannot rely on the timeout built-in with the session handling in PHP. This is useful for MNet or SSO.

Listing all the opened sessions of one user

This is mandatory to kill all the sessions of a specific user, or simply all like during upgrades.

Implementation

Session handler class that handles the sessions in DB

Pluggable session storage

• Rewrite of the file sessions
• Development of Memcached sessions
• No database storage, because we need a valid working session engine before migrating it

Pluggable lock system

Session handler class

This handles the basics:

• Storing the basic information in the database table.
• Retrieving the basic information from the database table.
• Setting up the handler session_set_save_handler()
• Acquiring the locks
• Deciding whether or not a session has timed out

Pluggable session storages

A class implementing the methods read, write, open, close, destroy and gc.

• Reads the data of a specific session id.
• Writes the data of of specific session id.
• Cleans up the data of a specific session id.
• Garbage collects, if not contradictory with sessions without timeout.

Pluggable lock system

See MDL-25500.

Design

interface \core\session\sessionable

Defines the strict minimum for a session system.

• session_exists()
• terminate_current()
• write_close()

abstract \core\session\driver implements \core\session\sessionable

Defines the required implementation of a session driver.

• protected check_user_initialised()
• protected prepare_cookies()
• protected security_check()

Callbacks.

• abstract handler_open()
• abstract handler_read()
• abstract handler_write()
• abstract handler_close()
• abstract handler_destroy()
• abstract handler_gc()

class \core\session\standard_handler extends \core\session\handler (better name?)

Default session handler, most of the logic will come from the current database_session class.

• Initialise everything
• Gets the lock in handler_read()
• Then gets the session info from session table
• Then asks the storage for data
• Tells the storage to write in handler_write()
• Then updates the record in session table
• Releases the lock in handler_close()

interface \core\session\storage

• init() (previously init_session_storage())
• open()
• read()
• write()
• close()
• destroy()
• gc($sids)

class \core\session\file_storage implements \core\session\storage

init()

Nothing

open()

touch the file.

read()

Returns the content of the session file.

write()

Writes to the file

destroy()

Removes the file

gc()

Nothing, but could perhaps delete very old session files, or receive a list of session ids to purge.

\core\session\memcached_storage

We need to use a session prefix, as well as site identifier, in case this would be shared.

init()

Nothing

open()

Nothing

read()

Initialise the connexion to Memcached, and returns the content of the session.

write()

Write the content to memcached.

destroy()

Remove the data from memcached.

gc()

Nothing, except if this receives a list of SID.

Questions

• A PHP timeout would possibly cause the session data to be lost. Though we can still ensure that the user is "logged in", we cannot guarantee that his session data is still valid unlike in the current DB system. Is that alright?

We do not lose anything because we entirely control what is deleted or stored via the handlers.

• How properly design the database storage so that it doesn't perform any extra query to write/read the session data in the session table?

We will not develop it yet.