[SCM] CTDB repository - branch master-readonly-records updated - ctdb-1.10-454-g1a76638

[Ronnie Sahlberg]

The branch, master-readonly-records has been updated
       via  1a766382d7d774aa3444e07401575e51d3704dba (commit)
      from  908a07c42e5135a3ba30a625fc4f4e4916de197a (commit)

http://gitweb.samba.org/?p=ctdb.git;a=shortlog;h=master-readonly-records


- Log -----------------------------------------------------------------
commit 1a766382d7d774aa3444e07401575e51d3704dba
Author: Ronnie Sahlberg <ronniesahlberg at gmail.com>
Date:   Thu Sep 1 11:40:51 2011 +1000

    ReadOnly: update the documentation about readonly locks

-----------------------------------------------------------------------

Summary of changes:
 doc/readonlyrecords.txt |   22 ++++++++++++++++++++--
 1 files changed, 20 insertions(+), 2 deletions(-)


Changeset truncated at 500 lines:

diff --git a/doc/readonlyrecords.txt b/doc/readonlyrecords.txt
index 6641b81..c07d583 100644
--- a/doc/readonlyrecords.txt
+++ b/doc/readonlyrecords.txt
@@ -47,8 +47,8 @@ Client-side implementation must be possible with only minor conditionals added t
 Implementation
 ==============
 
-Three new flags are allocated in the ctdb/ltdb record header.
-HAVE_DELEGATIONS, HAVE_READONLY_LOCK and REVOKING_READONLY
+Four new flags are allocated in the ctdb/ltdb record header.
+HAVE_DELEGATIONS, HAVE_READONLY_LOCK, REVOKING_READONLY and REVOKE_COMPLETE
 
 HAVE_DELEGATIONS is a flag that can only be set on the node that is currently the DMASTER for the record. When set, this
 flag indicates that there are Read-Only locks delegated to other nodes in the cluster for this record.
@@ -64,6 +64,24 @@ When the delegations are about to be revoked, the REVOKING_READONLY flag is set
 Once all delegations are revoked, both flags are cleared at the same time.
 While REVOKING_READONLY is set, any requests for the record, either normal request or request for readonly will be deferred.
 Deferred requests are linked to a list of deferred requests for the hash of the record until the time that the revokation is completed.
+This flags is set by the main ctdb daemon when it starts revoking this record.
+
+REVOKE_COMPLETE
+The actual revoke of records is done by a child process, spawned from the ctdb amin daemon when it starts the process to revoke the records.
+Once the child process has finished revoking all delegations, it will set the flag REVOKE_COMPLETE for this record to signal to the master daemon that the record has been successfully revoked.
+At this stage the child process will also trigger an event in the main daemon that revoke is complete, and that the main dameon should start re-processing all deferred calls.
+
+
+
+Once the revoke process is completed. There will be at least one deferred call to access this record, the initical call to for an exclusive fetch_lock() that triggered the revoke process to be started.
+In addition to nthis deferred call there may also be additional requests that have also become deferred while the revoke was in process. These can be either exclusive fetch_locks() or they can be other calls to request a new readonly lock on the record.
+Once the revoke is completed, the main daemon will reprocess all exclusive fetch_lock() requests immediately and respond to the clients.
+But any requests for readadonly locks will be deferred for an additional period of time before they are re-processed.
+This is to allow the client that needs a fetch_lock() to update the record to get some time to access and work on the record without having to compete with the possibly very many requests to get new readonly delegations created.
+
+
+
+
 
 
 The ctdbdb structure is expanded so that it contains one extra TDB database for each normal, non-persistent datbase.


-- 
CTDB repository