IReliableConcurrentQueue<T> Interface
Definition
Important
Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
Represents a reliable collection of persisted, replicated values with best-effort first-in first-out ordering.
public interface IReliableConcurrentQueue<T> : Microsoft.ServiceFabric.Data.IReliableState
type IReliableConcurrentQueue<'T> = interface
interface IReliableState
Public Interface IReliableConcurrentQueue(Of T)
Implements IReliableState
Type Parameters
- T
The type of the values contained in the reliable queue slim.
- Implements
Remarks
Intended as an alternative to IReliableQueue<T> for workloads where strict ordering is not required, as by relaxing the ordering constraint, concurrency can be greatly improved. IReliableQueue<T> restricts concurrent consumers and producers to a maximum of one each, while IReliableConcurrentQueue<T> imposes no such restriction.
IReliableConcurrentQueue<T> does not offer the same transaction isolation semantics as the other reliable data structures. See the individual operations and properties (EnqueueAsync(ITransaction, T, CancellationToken, Nullable<TimeSpan>), TryDequeueAsync(ITransaction, CancellationToken, Nullable<TimeSpan>) and Count) for details on what isolation, if any, they provide.
It is expected that values will be relatively short-lived in the queue; in other words, that the egress (TryDequeueAsync(ITransaction, CancellationToken, Nullable<TimeSpan>)) rate is equal to or greater than the ingress (EnqueueAsync(ITransaction, T, CancellationToken, Nullable<TimeSpan>)) rate. Violating this expectation may worsen system performance. A planned queue capacity constraint which will throttle incoming Enqueues once the capacity is reached will help in maintaining this property. property.
As the ordering of elements is not strictly guaranteed, assumptions about the ordering of any two values in the queue MUST NOT be made. The best-effort first-in first-out ordering is provided for fairness; the time that an value spends in the queue should be related to the failure rate (failures may alter the queue's ordering) and the dequeue rate, but not the enqueue rate.
IReliableConcurrentQueue<T> does not offer a Peek operation, however by combining TryDequeueAsync(ITransaction, CancellationToken, Nullable<TimeSpan>) and Abort() the same semantic can be achieved. See TryDequeueAsync(ITransaction, CancellationToken, Nullable<TimeSpan>) for additional details and an example.
Values stored in this queue MUST NOT be mutated outside the context of an operation on the queue. It is highly recommended to make T
immutable in order to avoid accidental data corruption.
Transaction is the unit of concurrency: Users can have multiple transactions in-flight at any given point of time but for a given transaction each API must be called one at a time. So all Reliable Collection APIs that take in a transaction and return a Task, must be awaited one at a time.
Properties
Count |
Gets the number of values in the IReliableConcurrentQueue<T>. |
Name |
Gets a value indicating the unique name for the IReliableState instance. (Inherited from IReliableState) |
Methods
EnqueueAsync(ITransaction, T, CancellationToken, Nullable<TimeSpan>) |
Stage the enqueue of a value into the queue. |
TryDequeueAsync(ITransaction, CancellationToken, Nullable<TimeSpan>) |
Tentatively dequeue a value from the queue. If the queue is empty, the dequeue operation will wait for an item to become available. |