Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

added paragraph on locking and merges

  • Loading branch information...
commit 7df52d7e49663c76dc9f87a18b42d71320a871cd 1 parent 5d7c7e1
Bela Ban authored January 21, 2011

Showing 1 changed file with 38 additions and 0 deletions. Show diff stats Hide diff stats

  1. 38  doc/manual/en/modules/blocks.xml
38  doc/manual/en/modules/blocks.xml
@@ -732,6 +732,44 @@
732 732
             <xref linkend="PEER_LOCK">PEER_LOCK</xref> and <xref linkend="CENTRAL_LOCK">CENTRAL_LOCK</xref>. The locking
733 733
             protocol has to be placed at or towards the top of the stack (close to the channel).
734 734
         </para>
  735
+        <section>
  736
+            <title>Locking and merges</title>
  737
+            <para>
  738
+                The following scenario is susceptible to merging: we have a cluster view of {A,B,C,D} and then the cluster
  739
+                splits into {A,B} and {C,D}. Assume that B and D now acquire a lock "mylock".
  740
+                This is what happens (with the locking protocol being CENTRAL_LOCK):
  741
+                <itemizedlist>
  742
+                    <listitem>There are 2 coordinators: A for {A,B} and C for {C,D}</listitem>
  743
+                    <listitem>B successfully acquires "mylock" from A</listitem>
  744
+                    <listitem>D successfully acquires "mylock" from C</listitem>
  745
+                    <listitem>The partitions merge back into {A,B,C,D}. Now, only A is the coordinator, but C ceases
  746
+                    to be a coordinator</listitem>
  747
+                    <listitem>Problem: D still holds a lock which should actually be invalid !</listitem>
  748
+                </itemizedlist>
  749
+                There is no easy way (via the Lock API) to 'remove' the lock from D. We could for example simply release
  750
+                D's lock on "mylock", but then there's no way telling D that the lock it holds is actually stale !
  751
+            </para>
  752
+            <para>
  753
+                Therefore the recommended solution here is for nodes to listen to MergeView changes if they expect
  754
+                merging to occur, and re-acquire all of their locks after a merge, e.g.:
  755
+                <screen>
  756
+                    Lock l1, l2, l3;
  757
+                    LockService lock_service;
  758
+                    ...
  759
+                    public void viewAccepted(View view) {
  760
+                        if(view instanceof MergeView) {
  761
+                            new Thread() {
  762
+                                public void run() {
  763
+                                    lock_service.unlockAll();
  764
+                                    // stop all access to resources protected by l1, l2 or l3
  765
+                                    // every thread needs to re-acquire the locks it holds
  766
+                                }
  767
+                            }.start
  768
+                        }
  769
+                    }
  770
+                </screen>
  771
+            </para>
  772
+        </section>
735 773
     </section>
736 774
   
737 775
     

0 notes on commit 7df52d7

Please sign in to comment.
Something went wrong with that request. Please try again.