Github user alpinegizmo commented on a diff in the pull request:
https://github.com/apache/flink/pull/5887#discussion_r184960782
--- Diff: docs/dev/stream/operators/process_function.md ---
@@ -271,16 +271,39 @@ override def onTimer(timestamp: Long, ctx:
OnTimerContext, out: Collector[OUT]):
</div>
</div>
-## Optimizations
+## Timers
-### Timer Coalescing
+Every timer registered via `registerEventTimeTimer()` or
`registerProcessingTimeTimer()` will be stored on `TimerService`
+and enqueued for execution.
-Every timer registered at the `TimerService` via
`registerEventTimeTimer()` or
-`registerProcessingTimeTimer()` will be stored on the Java heap and
enqueued for execution. There is,
-however, a maximum of one timer per key and timestamp at a millisecond
resolution and thus, in the
-worst case, every key may have a timer for each upcoming millisecond. Even
if you do not do any
-processing for outdated timers in `onTimer`, this may put a significant
burden on the
-Flink runtime.
+Invocations of `onTimer()` and `processElement()` are always synchronized,
so that users don't have to worry about
+concurrent modification of state.
+
+Note that there is a maximum of one timer per key and timestamp at a
millisecond resolution and thus, in the worst case,
+every key may have a timer for each upcoming millisecond. Even if you do
not do any processing for outdated timers in `onTimer`,
+this may put a significant burden on the Flink runtime.
+
+### Fault Tolerance
+
+Timers registered within `ProcessFunction` are fault tolerant. They are
synchronously checkpointed by Flink, regardless of
+configurations of state backends. (Therefore, a large number of timers can
significantly increase checkpointing time. See optimizations
+section for advice to reduce the number of timers.)
--- End diff --
See the optimizations section for advice on how to reduce the number of
timers.
---
