Clarified the order of watch events for TXN operations

Signed-off-by: Korenberg Mark <[email protected]>

Author: socketpair

content/en/docs/v3.4/learning/api_guarantees.md

@@ -53,6 +53,11 @@ Read more about [strict serializability].
 
 Strict serializability implies other weaker guarantees that might be easier to understand:
 
+For transactions without nested TXNs, the order of execution of operations
+is guaranteed to be the same as in its list of operations, which means stable
+GET responses within the transaction.
+For transactions with nested TXNs, the order of execution is not specified.
+
 #### Atomicity
 
 All API requests are atomic; an operation either completes entirely or not at
@@ -87,7 +92,10 @@ removes the performance penalty of linearized accesses' reliance on live consens
 Watches make guarantees about events:
 * Ordered - events are ordered by revision.
   An event will never appear on a watch if it precedes an event in time that
-  has already been posted.
+  has already been posted. For transactions without nested TXNs, the order of
+  generated events is guaranteed to be the same as in its list of operations.
+  For transactions with nested TXNs, the order of generated events is not
+  specified.
 * Unique - an event will never appear on a watch twice.
 * Reliable - a sequence of events will never drop any subsequence of events
   within the available history window. If there are events ordered in time as

content/en/docs/v3.5/learning/api_guarantees.md

@@ -53,6 +53,11 @@ Read more about [strict serializability].
 
 Strict serializability implies other weaker guarantees that might be easier to understand:
 
+For transactions without nested TXNs, the order of execution of operations
+is guaranteed to be the same as in its list of operations, which means stable
+GET responses within the transaction.
+For transactions with nested TXNs, the order of execution is not specified.
+
 #### Atomicity
 
 All API requests are atomic; an operation either completes entirely or not at
@@ -87,7 +92,10 @@ removes the performance penalty of linearized accesses' reliance on live consens
 Watches make guarantees about events:
 * Ordered - events are ordered by revision.
   An event will never appear on a watch if it precedes an event in time that
-  has already been posted.
+  has already been posted. For transactions without nested TXNs, the order of
+  generated events is guaranteed to be the same as in its list of operations.
+  For transactions with nested TXNs, the order of generated events is not
+  specified.
 * Unique - an event will never appear on a watch twice.
 * Reliable - a sequence of events will never drop any subsequence of events
   within the available history window. If there are events ordered in time as

content/en/docs/v3.6/learning/api_guarantees.md

@@ -53,6 +53,11 @@ Read more about [strict serializability].
 
 Strict serializability implies other weaker guarantees that might be easier to understand:
 
+For transactions without nested TXNs, the order of execution of operations
+is guaranteed to be the same as in its list of operations, which means stable
+GET responses within the transaction.
+For transactions with nested TXNs, the order of execution is not specified.
+
 #### Atomicity
 
 All API requests are atomic; an operation either completes entirely or not at
@@ -87,7 +92,10 @@ removes the performance penalty of linearized accesses' reliance on live consens
 Watches make guarantees about events:
 * Ordered - events are ordered by revision.
   An event will never appear on a watch if it precedes an event in time that
-  has already been posted.
+  has already been posted. For transactions without nested TXNs, the order of
+  generated events is guaranteed to be the same as in its list of operations.
+  For transactions with nested TXNs, the order of generated events is not
+  specified.
 * Unique - an event will never appear on a watch twice.
 * Reliable - a sequence of events will never drop any subsequence of events
   within the available history window. If there are events ordered in time as

content/en/docs/v3.7/learning/api_guarantees.md

@@ -53,6 +53,11 @@ Read more about [strict serializability].
 
 Strict serializability implies other weaker guarantees that might be easier to understand:
 
+For transactions without nested TXNs, the order of execution of operations
+is guaranteed to be the same as in its list of operations, which means stable
+GET responses within the transaction.
+For transactions with nested TXNs, the order of execution is not specified.
+
 #### Atomicity
 
 All API requests are atomic; an operation either completes entirely or not at
@@ -87,7 +92,10 @@ removes the performance penalty of linearized accesses' reliance on live consens
 Watches make guarantees about events:
 * Ordered - events are ordered by revision.
   An event will never appear on a watch if it precedes an event in time that
-  has already been posted.
+  has already been posted. For transactions without nested TXNs, the order of
+  generated events is guaranteed to be the same as in its list of operations.
+  For transactions with nested TXNs, the order of generated events is not
+  specified.
 * Unique - an event will never appear on a watch twice.
 * Reliable - a sequence of events will never drop any subsequence of events
   within the available history window. If there are events ordered in time as