You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For a discussion of errors affecting multi-document ACID transactions, see xref:howtos:distributed-acid-transactions-from-the-sdk.adoc#error-handling[our documentation on transactions from the .NET SDK].
33
+
For a discussion of errors affecting multi-document ACID transactions, see xref:concept-docs:transactions-error-handling.adoc#error-handling[our documentation on transactions from the .NET SDK].
|`CleanupWindow`|60 seconds|This determines how long a cleanup 'run' is; that is, how frequently this client will check its subset of ATR documents. It is perfectly valid for the application to change this setting, which is at a conservative default. Decreasing this will cause expiration transactions to be found more swiftly (generally, within this cleanup window), with the tradeoff of increasing the number of reads per second used for the scanning process.
23
+
|`CleanupLostAttempts`|true|This is the thread that takes part in the distributed cleanup process described above, that cleans up expired transactions created by any client. It is strongly recommended that it is left enabled.
24
+
|`CleanupClientAttempts`|true|This thread is for cleaning up transactions created just by this client. The client will preferentially aim to send any transactions it creates to this thread, leaving transactions for the distributed cleanup process only when it is forced to (for example, on an application crash). It is strongly recommended that it is left enabled.
25
+
|===
26
+
27
+
// TODO: Add this for .NET when available
28
+
////
29
+
=== Monitoring Cleanup
30
+
31
+
If the application wishes to monitor cleanup it may subscribe to these events:
`TransactionCleanupEndRunEvent` is raised whenever a current 'run' is finished, and contains statistics from the run.
39
+
(A run is typically around every 60 seconds, with default configuration.)
40
+
41
+
A `TransactionCleanupAttempt` event is raised when an expired transaction was found by this process, and a cleanup attempt was made.
42
+
It contains whether that attempt was successful, along with any logs relevant to the attempt.
43
+
44
+
In addition, if cleanup fails to cleanup a transaction that is more than two hours past expiry, it will raise the `TransactionCleanupAttempt` event at WARN level (rather than the default DEBUG).
45
+
With most default configurations of the event-bus (see <<Logging>> below), this will cause that event to be logged somewhere visible to the application.
46
+
If there is not a good reason for the cleanup to be failed (such as a downed node that has not yet been failed-over), then the user is encouraged to report the issue.
TIP: Committing is automatic: if there is no explicit call to `ctx.CommitAsync()` at the end of the transaction logic callback, and no exception is thrown, it will be committed.
28
+
29
+
=== Rollback
30
+
31
+
When an exception is thrown, either by the application from the {lambda}, or by the transactions logic itself (e.g. on a failed operation), then that attempt is rolled back.
32
+
33
+
The application's {lambda} may or may not be retried, depending on the error that occurred.
34
+
The general rule for retrying is whether the transaction is likely to succeed on a retry.
35
+
For example, if this transaction is trying to write a document that is currently involved in another transaction (a write-write conflict), this will lead to a retry as that is likely a transient state.
36
+
But if the transaction is trying to get a document that does not exist, it will not retry.
37
+
38
+
If the transaction is not retried then it will throw a `{transaction-failed}`.
In this case, if `ctx.RollbackAsync()` is reached, then the transaction will be regarded as successfully rolled back and no `{transaction-failed}` will be thrown.
53
+
54
+
After a transaction is rolled back, it cannot be committed, no further operations are allowed on it, and the SDK will not try to automatically commit it at the end of the code block.
0 commit comments