Update

Author: spelluru

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

@@ -1,5 +1,5 @@
 ---
-title: Azure Service Bus message transfers, locks, and settlement
+title: Message transfers, locks, and settlement
 description: This article provides an overview of Azure Service Bus message transfers, locks, and settlement operations.
 ms.topic: article
 ms.date: 03/21/2025
@@ -9,7 +9,7 @@ ms.custom: devx-track-csharp
 
 # Message transfers, locks, and settlement
 
-The central capability of a message broker such as Service Bus is to accept messages into a queue or topic and hold them available for later retrieval. *Send* is the term that is commonly used for the transfer of a message into the message broker. *Receive* is the term commonly used for the transfer of a message to a retrieving client.
+The central capability of a message broker such as Service Bus is to accept messages into a queue or topic and hold them available for later retrieval. The term *send* is used to describe the process of transferring a message to the message broker, while *receive* refers to the process of retrieving a message from the broker.
 
 When a client sends a message, it usually wants to know whether the message is properly transferred to and accepted by the broker or whether some sort of error occurred. This positive or negative acknowledgment settles the understanding of both the client and broker about the transfer state of the message. Therefore, it's referred to as a *settlement*.
 
@@ -124,7 +124,7 @@ The typical mechanism for identifying duplicate message deliveries is by checkin
 >   * Changing properties on the entity (Queue, Topic, Subscription) while holding the lock.
 >   * If the Service Bus Client application loses its connection to the Service Bus for any reason.
 >
-> When the lock is lost, Azure Service Bus will generate a MessageLockLostException or SessionLockLostException, which will surface in the client application. In this case, the client's default retry logic should automatically kick in and retry the operation. Moreover, the delivery count of the message won't be incremented.
+> When the lock is lost, Azure Service Bus generates a MessageLockLostException or SessionLockLostException, which surfaces in the client application. In this case, the client's default retry logic should automatically kick in and retry the operation. Moreover, the delivery count of the message isn't incremented.
 
 ## Renew locks
 The default value for the lock duration is **1 minute**. You can specify a different value for the lock duration at the [queue](/dotnet/api/azure.messaging.servicebus.administration.createqueueoptions.lockduration) or [subscription](/dotnet/api/azure.messaging.servicebus.administration.createsubscriptionoptions.lockduration) level. The client owning the lock can renew the message lock by using methods on the receiver object. Instead, you can use the automatic lock-renewal feature where you can specify the time duration for which you want to keep getting the lock renewed.