Acrolynx

Author: spelluru

articles/service-bus-messaging/message-transfers-locks-settlement.md

@@ -115,10 +115,10 @@ The `Complete`, `DeadLetter`, or `RenewLock` operations might fail due to networ
 
 If `Complete` fails, which occurs typically at the very end of message handling and in some cases after minutes of processing work, the receiving application can decide whether to preserve the state of the work and ignore the same message when it's delivered a second time, or whether to toss out the work result and retries as the message is redelivered.
 
-The typical mechanism for identifying duplicate message deliveries is by checking the message-id, which can and should be set by the sender to a unique value, possibly aligned with an identifier from the originating process. A job scheduler would likely set the message-id to the identifier of the job it's trying to assign to a worker with the given worker, and the worker would ignore the second occurrence of the job assignment if that job is already done.
+The typical mechanism for identifying duplicate message deliveries is by checking the `message-id`, which can and should be set by the sender to a unique value, possibly aligned with an identifier from the originating process. A job scheduler would likely set the `message-id` to the identifier of the job it's trying to assign to a worker with the given worker, and the worker would ignore the second occurrence of the job assignment if that job is already done.
 
 > [!IMPORTANT]
-> It is important to note that the lock that PeekLock or SessionLock acquires on the message is volatile and may be lost in the following conditions
+> It's important to note that the lock that PeekLock or SessionLock acquires on the message is volatile and can be lost in the following conditions
 >   * Service Update
 >   * OS update
 >   * Changing properties on the entity (Queue, Topic, Subscription) while holding the lock.