From 1d29920562b3c714e15f8ed1b0cc0297a336d3fe Mon Sep 17 00:00:00 2001 From: dsyer Date: Thu, 12 Nov 2009 17:13:33 +0000 Subject: [PATCH] Spelling --- src/site/apt/transactions.apt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/site/apt/transactions.apt b/src/site/apt/transactions.apt index c47d26239..1a1b75915 100644 --- a/src/site/apt/transactions.apt +++ b/src/site/apt/transactions.apt @@ -86,7 +86,7 @@ Batch Processing and Transactions +--- The inner RETRY(4) block is marked as "stateful" - see the - {{{#Typical}typical}} use case for a description of an stateful + {{{#Typical}typical}} use case for a description of a stateful retry. This means that if the the retry PROCESS(5) block fails, the behaviour of the RETRY(4) is as follows. @@ -205,7 +205,7 @@ Batch Processing and Transactions Interactions Between Batching and Transaction Propagation There is a tighter coupling between batch-retry and TX management - than we would ideally like. In particular an stateless retry cannot + than we would ideally like. In particular a stateless retry cannot be used to retry database operations with a transaction manager that doesn't support NESTED propagation. @@ -302,9 +302,9 @@ Interactions Between Batching and Transaction Propagation * Stateless Retry Cannot Recover - The distinction between an stateless and an stateful retry in the + The distinction between a stateless and a stateful retry in the {{{#Typical}typical}} example above is important. It is actually - ultimately a transactional constraint that forces the distiction, + ultimately a transactional constraint that forces the distinction, and this constraint also makes it obvious why the distinction exists. @@ -334,7 +334,7 @@ Interactions Between Batching and Transaction Propagation | } +--- - Here we have an stateless RETRY(3) with a RECOVER(5) path that kicks + Here we have a stateless RETRY(3) with a RECOVER(5) path that kicks in after the final attempt fails. The "stateless" label just means that the block will be repeated without rethrowing any exception up to some limit. This will only work if the transaction TX(4) has