summaryrefslogtreecommitdiff
path: root/modules/system
diff options
context:
space:
mode:
authorJennifer Hodgdon <yahgrp@poplarware.com>2013-03-20 09:08:04 -0700
committerJennifer Hodgdon <yahgrp@poplarware.com>2013-03-20 09:08:04 -0700
commit6cb8c8a05220a334ee8542097b48cf0a2a5dced2 (patch)
tree93b3958513047382b4a7ba4a8d836ca70776d0a4 /modules/system
parente01afb83bc7bffc84ddda0d3b3da7b505aedeed7 (diff)
downloadbrdo-6cb8c8a05220a334ee8542097b48cf0a2a5dced2.tar.gz
brdo-6cb8c8a05220a334ee8542097b48cf0a2a5dced2.tar.bz2
Issue #1926758 by balsama, mitron: Fix code comment in system.module
Diffstat (limited to 'modules/system')
-rw-r--r--modules/system/system.module23
1 files changed, 12 insertions, 11 deletions
diff --git a/modules/system/system.module b/modules/system/system.module
index d47ab8a81..2bbcd7fcf 100644
--- a/modules/system/system.module
+++ b/modules/system/system.module
@@ -1907,17 +1907,18 @@ function system_init() {
// Ignore slave database servers for this request.
//
- // In Drupal's distributed database structure, new data is written to the master
- // and then propagated to the slave servers. This means there is a lag
- // between when data is written to the master and when it is available on the slave.
- // At these times, we will want to avoid using a slave server temporarily.
- // For example, if a user posts a new node then we want to disable the slave
- // server for that user temporarily to allow the slave server to catch up.
- // That way, that user will see their changes immediately while for other
- // users we still get the benefits of having a slave server, just with slightly
- // stale data. Code that wants to disable the slave server should use the
- // db_set_ignore_slave() function to set $_SESSION['ignore_slave_server'] to
- // the timestamp after which the slave can be re-enabled.
+ // In Drupal's distributed database structure, new data is written to the
+ // master and then propagated to the slave servers. This means there is a
+ // lag between when data is written to the master and when it is available on
+ // the slave. At these times, we will want to avoid using a slave server
+ // temporarily. For example, if a user posts a new node then we want to
+ // disable the slave server for that user temporarily to allow the slave
+ // server to catch up. That way, that user will see their changes immediately
+ // while for other users we still get the benefits of having a slave server,
+ // just with slightly stale data. Code that wants to disable the slave
+ // server should use the db_ignore_slave() function to set
+ // $_SESSION['ignore_slave_server'] to the timestamp after which the slave
+ // can be re-enabled.
if (isset($_SESSION['ignore_slave_server'])) {
if ($_SESSION['ignore_slave_server'] >= REQUEST_TIME) {
Database::ignoreTarget('default', 'slave');