Skip to content

Commit 25dc499

Browse files
authored
Update timers-and-reminders.md to reflect Orleans v8.2.0 grain timers changes (#43920)
1 parent efaeecb commit 25dc499

File tree

1 file changed

+15
-7
lines changed

1 file changed

+15
-7
lines changed

docs/orleans/grains/timers-and-reminders.md

Lines changed: 15 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -10,19 +10,19 @@ The Orleans runtime provides two mechanisms, called timers and reminders, that e
1010

1111
## Timers
1212

13-
**Timers** are used to create periodic grain behavior that isn't required to span multiple activations (instantiations of the grain). A timer is identical to the standard .NET <xref:System.Threading.Timer?displayProperty=fullName> class. In addition, timers are subject to single-threaded execution guarantees within the grain activation that they operate on, and their executions are interleaved with other requests, as though the timer callback was a grain method marked with <xref:Orleans.Concurrency.AlwaysInterleaveAttribute>.
13+
**Timers** are used to create periodic grain behavior that isn't required to span multiple activations (instantiations of the grain). A timer is identical to the standard .NET <xref:System.Threading.Timer?displayProperty=fullName> class. In addition, timers are subject to single-threaded execution guarantees within the grain activation that they operate on.
1414

1515
Each activation may have zero or more timers associated with it. The runtime executes each timer routine within the runtime context of the activation that it's associated with.
1616

1717
## Timer usage
1818

19-
To start a timer, use the `RegisterGrainTimer` method, which returns an <xref:System.IDisposable> reference:
19+
To start a timer, use the `RegisterGrainTimer` method, which returns an <xref:Orleans.Runtime.IGrainTimer> reference:
2020

2121
```csharp
22-
protected IDisposable RegisterGrainTimer(
23-
Func<object, Task> callback, // function invoked when the timer ticks
24-
object state, // object to pass to callback
25-
GrainTimerCreationOptions options) // timer creation options
22+
protected IGrainTimer RegisterGrainTimer<TState>(
23+
Func<TState, CancellationToken, Task> callback, // function invoked when the timer ticks
24+
TState state, // object to pass to callback
25+
GrainTimerCreationOptions options) // timer creation options
2626
```
2727

2828
To cancel the timer, you dispose of it.
@@ -33,7 +33,15 @@ A timer ceases to trigger if the grain is deactivated or when a fault occurs and
3333

3434
* When activation collection is enabled, the execution of a timer callback doesn't change the activation's state from idle to in-use. This means that a timer can't be used to postpone the deactivation of otherwise idle activations.
3535
* The period passed to `Grain.RegisterGrainTimer` is the amount of time that passes from the moment the `Task` returned by `callback` is resolved to the moment that the next invocation of `callback` should occur. This not only makes it impossible for successive calls to `callback` to overlap, but also makes it so that the length of time `callback` takes to complete affects the frequency at which `callback` is invoked. This is an important deviation from the semantics of <xref:System.Threading.Timer?displayProperty=fullName>.
36-
* Each invocation of `callback` is delivered to an activation on a separate turn, and never runs concurrently with other turns on the same activation. However, `callback` invocations aren't delivered as messages and thus aren't subject to message interleaving semantics. This means that invocations of `callback` behave as if the grain is re-entrant and executes concurrently with other grain requests. In order to use the grain's request scheduling semantics, you can call a grain method to perform the work you would have done within `callback`. Another alternative is to use an `AsyncLock` or a <xref:System.Threading.SemaphoreSlim>. A more detailed explanation is available in [Orleans GitHub issue #2574](https://github.com/dotnet/orleans/issues/2574).
36+
* Each invocation of `callback` is delivered to an activation on a separate turn, and never runs concurrently with other turns on the same activation.
37+
* Callbacks do not interleave by default. Interleaving can be enabled by setting Interleave to true on GrainTimerCreationOptions.
38+
* Grain timers can be updated using the Change(TimeSpan, TimeSpan) method on the returned IGrainTimer instance.
39+
* Callbacks can keep the grain active, preventing it from being collected if the timer period is relatively short. This can be enabled by setting KeepAlive to true on GrainTimerCreationOptions.
40+
* Callbacks can receive a CancellationToken which is canceled when the timer is disposed or the grain starts to deactivate.
41+
* Callbacks can dispose the grain timer which fired them.
42+
* Callbacks are subject to grain call filters.
43+
* Callbacks are visible in distributed tracing, when distributed tracing is enabled.
44+
* POCO grains (grain classes which do not inherit from Grain) can register grain timers using the RegisterGrainTimer extension method.
3745

3846
## Reminders
3947

0 commit comments

Comments
 (0)