Merge branch 'uw/mnesia-majority' into dev

* uw/mnesia-majority:
  dialyzer warning on mnesia_tm
  Add documentation text about majority checking
  add mnesia_majority_test suite
  where_to_wlock optimization + change_table_majority/2
  bug in mnesia_tm:needs_majority/2
  optimize sticky_lock maj. check
  check majority for sticky locks
  Write locks now check majority when needed.
  Add {majority, boolean()} per-table option.

OTP-9304

1 files changed, 7 insertions, 0 deletions

diff --git a/lib/mnesia/doc/src/Mnesia_chap7.xmlsrc b/lib/mnesia/doc/src/Mnesia_chap7.xmlsrc
index 7078499fbf..21174340d1 100644
--- a/lib/mnesia/doc/src/Mnesia_chap7.xmlsrc
+++ b/lib/mnesia/doc/src/Mnesia_chap7.xmlsrc
@@ -473,6 +473,13 @@ dets:close(N).      </pre>
       <c>mnesia:table_info(Tab, master_nodes)</c> may be used to
       obtain information about the potential master nodes.
       </p>
+    <p>Determining which data to keep after communication failure is outside
+    the scope of Mnesia. One approach would be to determine which "island"
+    contains a majority of the nodes. Using the <c>{majority,true}</c> option
+    for critical tables can be a way of ensuring that nodes that are not part
+    of a "majority island" are not able to update those tables. Note that this
+    constitutes a reduction in service on the minority nodes. This would be
+    a tradeoff in favour of higher consistency guarantees.</p>
     <p>The function <c>mnesia:force_load_table(Tab)</c> may be used to
       force load the table regardless of which table load mechanism
       is activated.