Skip to content

Commit bd0b955

Browse files
Merge pull request #274803 from PesalaPavan/patch-12
(AzureCXP) fixes MicrosoftDocs/azure-docs#122316
2 parents fa2526b + dde5be8 commit bd0b955

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

articles/iot-operations/develop/concept-about-state-store-protocol.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -276,7 +276,7 @@ Assume that `Client1` goes first with a request of `SET LockName Client1 NEX PX
276276

277277
When `Client1` successfully does a `SET` ("AquireLock") on `LockName`, the state store returns the version of `LockName` as a Hybrid Logical Clock (HLC) in the MQTT5 user property `__ts`.
278278

279-
When a client performs a `SET` request, it can optionally include the MQTT5 user property `__ft` to represent a "fencing token". The __ft` is represented as an HLC. The fencing token associated with a given key-value pair provides lock ownership checking. The fencing token can come from anywhere. For this scenario, it should come from the version of `LockName`.
279+
When a client performs a `SET` request, it can optionally include the MQTT5 user property `__ft` to represent a "fencing token". The `__ft` is represented as an HLC. The fencing token associated with a given key-value pair provides lock ownership checking. The fencing token can come from anywhere. For this scenario, it should come from the version of `LockName`.
280280

281281
The following diagram shows the process of `Client1` doing a `SET` request on `LockName`:
282282

0 commit comments

Comments
 (0)