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
Copy file name to clipboardExpand all lines: articles/service-bus-messaging/message-sessions.md
+10-10Lines changed: 10 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
title: Azure Service Bus message sessions | Microsoft Docs
3
3
description: This article explains how to use sessions to enable joint and ordered handling of unbounded sequences of related messages.
4
4
ms.topic: article
5
-
ms.date: 02/14/2023
5
+
ms.date: 02/23/2024
6
6
---
7
7
8
8
# Message sessions
@@ -29,15 +29,15 @@ For samples, use links in the [Next steps](#next-steps) section.
29
29
30
30
### Session features
31
31
32
-
Sessions provide concurrent de-multiplexing of interleaved message streams while preserving and guaranteeing ordered delivery.
32
+
Sessions provide concurrent demultiplexing of interleaved message streams while preserving and guaranteeing ordered delivery.
33
33
34
-
![A diagram showing how the Sessions feature preserves ordered delivery.][1]
34
+
:::image type="content" source="./media/message-sessions/sessions.png" alt-text="Diagram that shows how the Sessions feature preserves an ordered delivery.":::
35
35
36
-
A session receiver is created by a client accepting a session. When the session is accepted and held by a client, the client holds an exclusive lock on all messages with that session's **session ID** in the queue or subscription. It will also hold exclusive locks on all messages with the **session ID** that will arrive later.
36
+
A session receiver is created by a client accepting a session. When the session is accepted and held by a client, the client holds an exclusive lock on all messages with that session's **session ID** in the queue or subscription. It holds exclusive locks on all messages with the **session ID** that arrive later.
37
37
38
38
The lock is released when you call close methods on the receiver or when the lock expires. There are methods on the receiver to renew the locks as well. 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. The session lock should be treated like an exclusive lock on a file, meaning that the application should close the session as soon as it no longer needs it and/or doesn't expect any further messages.
39
39
40
-
When multiple concurrent receivers pull from the queue, the messages belonging to a particular session are dispatched to the specific receiver that currently holds the lock for that session. With that operation, an interleaved message stream in one queue or subscription is cleanly de-multiplexed to different receivers and those receivers can also live on different client machines, since the lock management happens service-side, inside Service Bus.
40
+
When multiple concurrent receivers pull from the queue, the messages belonging to a particular session are dispatched to the specific receiver that currently holds the lock for that session. With that operation, an interleaved message stream in one queue or subscription is cleanly demultiplexed to different receivers and those receivers can also live on different client machines, since the lock management happens service-side, inside Service Bus.
41
41
42
42
The previous illustration shows three concurrent session receivers. One Session with `SessionId` = 4 has no active, owning client, which means that no messages are delivered from this specific session. A session acts in many ways like a sub queue.
43
43
@@ -51,7 +51,7 @@ The session state facility enables an application-defined annotation of a messag
51
51
52
52
From the Service Bus perspective, the message session state is an opaque binary object that can hold data of the size of one message, which is 256 KB for Service Bus Standard, and 100 MB for Service Bus Premium. The processing state relative to a session can be held inside the session state, or the session state can point to some storage location or database record that holds such information.
53
53
54
-
The methods for managing session state, SetState and GetState, can be found on the session receiver object. A session that had previously no session state returns a null reference for GetState. The previously set session state can be cleared by passing null to the SetState method on the receiver.
54
+
The methods for managing session state, `SetState` and `GetState`, can be found on the session receiver object. A session that had previously no session state returns a null reference for `GetState`. The previously set session state can be cleared by passing null to the `SetState` method on the receiver.
55
55
56
56
Session state remains as long as it isn't cleared up (returning **null**), even if all messages in a session are consumed.
57
57
@@ -90,7 +90,7 @@ So, the messages are processed in this order: message 2, message 3, and message
90
90
If messages just need to be retrieved in order, you don't need to use sessions. If messages need to be processed in order, use sessions. The same session ID should be set on messages that belong together, which could be message 1, 4, and 8 in a set, and 2, 3, and 6 in another set.
91
91
92
92
## Message expiration
93
-
For session-enabled queues or topics' subscriptions, messages are locked at the session level. If the TTL for any of the messages expires, all messages related to that session are either dropped or dead-lettered based on the dead-lettering enabled on messaging expiration setting on the entity. In other words, if there's a single message in the session that has passed the TTL, all the messages in the session are expired. The messages expire only if there's an active listener. For more information, see [Message expiration](message-expiration.md).
93
+
For session-enabled queues or topics' subscriptions, messages are locked at the session level. If the time-to-live (TTL) for any of the messages expires, all messages related to that session are either dropped or dead-lettered based on the dead-lettering enabled on messaging expiration setting on the entity. In other words, if there's a single message in the session that has passed the TTL, all the messages in the session are expired. The messages expire only if there's an active listener. For more information, see [Message expiration](message-expiration.md).
94
94
95
95
## Next steps
96
96
You can enable message sessions while creating a queue using Azure portal, PowerShell, CLI, Resource Manager template, .NET, Java, Python, and JavaScript. For more information, see [Enable message sessions](enable-message-sessions.md).
@@ -112,9 +112,9 @@ Try the samples in the language of your choice to explore Azure Service Bus feat
112
112
-[Continually read through all available sessions](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/servicebus/service-bus/samples/v7/javascript/advanced/sessionRoundRobin.js)
0 commit comments