This is an automated email from the ASF dual-hosted git repository.
duhengforever pushed a commit to branch develop
in repository https://gitbox.apache.org/repos/asf/rocketmq.git
The following commit(s) were added to refs/heads/develop by this push:
new 41f58e4 [ISSUE #3774] docs: Polish the document
'Example_Transaction.md'. (#3775)
41f58e4 is described below
commit 41f58e4b86712a36c240735daa572916964d722a
Author: 彭小漪 <[email protected]>
AuthorDate: Wed Jan 19 20:14:34 2022 +0800
[ISSUE #3774] docs: Polish the document 'Example_Transaction.md'. (#3775)
---
docs/en/Example_Transaction.md | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/docs/en/Example_Transaction.md b/docs/en/Example_Transaction.md
index 5d1cff9..e217073 100644
--- a/docs/en/Example_Transaction.md
+++ b/docs/en/Example_Transaction.md
@@ -2,9 +2,9 @@
## 1 Transaction message status
There are three states for transaction message:
-- TransactionStatus.CommitTransaction: commit transaction, it means that allow
consumers to consume this message.
-- TransactionStatus.RollbackTransaction: rollback transaction, it means that
the message will be deleted and not allowed to consume.
-- TransactionStatus.Unknown: intermediate state, it means that MQ is needed to
check back to determine the status.
+- LocalTransactionState.COMMIT_MESSAGE: commit transaction, it means that
allow consumers to consume this message.
+- LocalTransactionState.ROLLBACK_MESSAGE: rollback transaction, it means that
the message will be deleted and not allowed to consume.
+- LocalTransactionState.UNKNOW: intermediate state, it means that MQ is needed
to check back to determine the status.
## 2 Send transactional message example
@@ -91,6 +91,6 @@ public class TransactionListenerImpl implements
TransactionListener {
2. In order to avoid a single message being checked too many times and lead to
half queue message accumulation, we limited the number of checks for a single
message to 15 times by default, but users can change this limit by change the
```transactionCheckMax``` parameter in the configuration of the broker, if one
message has been checked over ```transactionCheckMax``` times, broker will
discard this message and print an error log at the same time by default. Users
can change this behav [...]
3. A transactional message will be checked after a certain period of time that
determined by parameter ```transactionTimeout``` in the configuration of the
broker. And users also can change this limit by set user property
```CHECK_IMMUNITY_TIME_IN_SECONDS``` when sending transactional message, this
parameter takes precedence over the ```transactionTimeout``` parameter.
4. A transactional message maybe checked or consumed more than once.
-5. Committed message reput to the user’s target topic may fail. Currently, it
depends on the log record. High availability is ensured by the high
availability mechanism of RocketMQ itself. If you want to ensure that the
transactional message isn’t lost and the transaction integrity is guaranteed,
it is recommended to use synchronous double write. mechanism.
-6. Producer IDs of transactional messages cannot be shared with producer IDs
of other types of messages. Unlike other types of message, transactional
messages allow backward queries. MQ Server query clients by their Producer IDs.
+5. Committed message reput to the user’s target topic may fail. Currently, it
depends on the log record. High availability is ensured by the high
availability mechanism of RocketMQ itself. If you want to ensure that the
transactional message isn’t lost and the transaction integrity is guaranteed,
it is recommended to use synchronous double write mechanism.
+6. `producerGroup` for producers of transactional messages cannot be shared
with `producerGroup` for producers of other types of messages. Unlike other
types of message, transactional messages allow backward queries. MQ Server
query clients by their `producerGroup` of producers.
