[Erp5-report] r25807 - /erp5/trunk/products/TIDStorage/README

[nobody at svn.erp5.org]

Author: luke
Date: Tue Mar  3 11:29:25 2009
New Revision: 25807

URL: http://svn.erp5.org?rev=25807&view=rev
Log:
 - spellchecking

Modified:
    erp5/trunk/products/TIDStorage/README

Modified: erp5/trunk/products/TIDStorage/README
URL: http://svn.erp5.org/erp5/trunk/products/TIDStorage/README?rev=25807&r1=25806&r2=25807&view=diff
==============================================================================
--- erp5/trunk/products/TIDStorage/README [utf8] (original)
+++ erp5/trunk/products/TIDStorage/README [utf8] Tue Mar  3 11:29:25 2009
@@ -6,22 +6,22 @@
 Doing backups of individual Data.fs who are part of the same instance
 (one mounted in another) is a problem when there are transactions involving
 multiple storages: if there is a crash during transaction commit, there is no
-way to tell which storage was commited and which was not (there is no TID
+way to tell which storage was committed and which was not (there is no TID
 consistency between databases).
 There is an even more tricky case. Consider the following:
  2 transactions running in parallel:
   T1: modifies storage A and B
   T2: modifies storage A
  Commit order scenario:
-  T1 starts commiting (takes commit lock on A and B)
-  T2 starts commiting (waits for commit lock on A)
+  T1 starts committing (takes commit lock on A and B)
+  T2 starts committing (waits for commit lock on A)
   T1 commits A (commit lock released on A)
   T2 commits A (takes & releases commit lock on A)
   [crash]
   T1 commits B (commit lock released on B) <- never happens because of crash
 
-Here, T2 was able to commit entierely, but it must not be saved. This is
-because transactions are stored in ZODB in the order they are commited.
+Here, T2 was able to commit entirely, but it must not be saved. This is
+because transactions are stored in ZODB in the order they are committed.
 So is T2 is in the backup, a part of T1 will also be, and backup will be
 inconsistent (T1 commit on B never happened).  
 
@@ -36,8 +36,8 @@
      _commitResource method to know when it happens.
      It must be configured to fit your network setup (TID_STORAGE_ADDRESS)
    ZEO patch:
-     With regular ZEO, there is no way to know last commited TID at
-     transaction-code level. This patch stores last commited TID on ZEO
+     With regular ZEO, there is no way to know last committed TID at
+     transaction-code level. This patch stores last committed TID on ZEO
      connection object, to be read by transaction patch.
  - A daemon
    This is TIDStorage itself, receiving TIDs from Zopes and delivering
@@ -91,7 +91,7 @@
      bar\n
      baz\n
  When transferring a dict, it is prepended by the number of items, followed by
- keys and then values. Values must be ints represented as strings.
+ keys and then values. Values must be integers represented as strings.
    Example:
      2\n
      key1\n
@@ -125,7 +125,7 @@
 
 COMMIT\n
 <commit id>\n
-<dict of involved storages and commited TIDs>
+<dict of involved storages and committed TIDs>
 
  <commit id>: (cf. BEGIN)
  involved storages: (cf. BEGIN)