Session locks: Difference between revisions
mNo edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
When you create a | When you create a normal moodle page and include config.php then by default a large amount of moodle bootstrapping runs and you will have the $SESSION global setup for you. | ||
== Session unlocking == | |||
By default core assumes that you might need to mutate the $SESSION object so it will hold a lock on the session until the page finished and a shutdown handler will release the session lock. | |||
If you are working on any page which is potentially long running, then you should cleanly separate logic which runs early which could mutate the session from the long running processin code and unlock the session. | |||
\core\session\manager::write_close | |||
== Read only session in pages == | |||
If you know ahead of time that you will never mutate the session, but you still need to be able to read it, then you can declare your page to be read only. This will mean your page will never block the session in another http request. | |||
define('READ_ONLY_SESSION', true); | |||
ABORT_AFTER_CONFIG | == Read only sessions in web services == | ||
The same is possible in web services. When you declare your web service you can specify it will not need a session lock: | |||
'core_message_get_unread_conversations_count' => array( | |||
'classname' => 'core_message_external', | |||
'methodname' => 'get_unread_conversations_count', | |||
'classpath' => 'message/externallib.php', | |||
'description' => 'Retrieve the count of unread conversations for a given user', | |||
'type' => 'read', | |||
'ajax' => true, | |||
'services' => array(MOODLE_OFFICIAL_MOBILE_SERVICE), | |||
'''<nowiki>'readonlysession' => true, // We don't modify the session.</nowiki>''' | |||
), | |||
== No session at all == | |||
If your script doesn't actually need $SESSION in the first place then save even more processing and locks by declaring: | |||
define('NO_MOODLE_COOKIES', true); | |||
== No config is needed == | |||
Going to the absolute extreme, if you do not even need the full moodle bootstrap to run then you can skip it via: | |||
define('ABORT_AFTER_CONFIG', true); |
Revision as of 02:34, 16 March 2022
When you create a normal moodle page and include config.php then by default a large amount of moodle bootstrapping runs and you will have the $SESSION global setup for you.
Session unlocking
By default core assumes that you might need to mutate the $SESSION object so it will hold a lock on the session until the page finished and a shutdown handler will release the session lock.
If you are working on any page which is potentially long running, then you should cleanly separate logic which runs early which could mutate the session from the long running processin code and unlock the session.
\core\session\manager::write_close
Read only session in pages
If you know ahead of time that you will never mutate the session, but you still need to be able to read it, then you can declare your page to be read only. This will mean your page will never block the session in another http request.
define('READ_ONLY_SESSION', true);
Read only sessions in web services
The same is possible in web services. When you declare your web service you can specify it will not need a session lock:
'core_message_get_unread_conversations_count' => array( 'classname' => 'core_message_external', 'methodname' => 'get_unread_conversations_count', 'classpath' => 'message/externallib.php', 'description' => 'Retrieve the count of unread conversations for a given user', 'type' => 'read', 'ajax' => true, 'services' => array(MOODLE_OFFICIAL_MOBILE_SERVICE), 'readonlysession' => true, // We don't modify the session. ),
No session at all
If your script doesn't actually need $SESSION in the first place then save even more processing and locks by declaring:
define('NO_MOODLE_COOKIES', true);
No config is needed
Going to the absolute extreme, if you do not even need the full moodle bootstrap to run then you can skip it via:
define('ABORT_AFTER_CONFIG', true);