VLDB 2026 Research / reviewers in the wild / expert
Jaroslaw Cwiklik
dblp:118/2278
· DBLP profile ↗
1ranked-venue papers
0as first author
1since 2021 · last 2023
0009-0001-0383-6626ORCID · reported
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 1 · 1 since 2021
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Distributed systems · 100% | |
| Software engineering, system software, and programming languages
1 paper |
Concurrent programming · 100% |
Topics — the 3 heaviest of 3, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Concurrent programming › concurrency theory
process calculi |
0.7 | 1 | 2023 | Reliable Actors with Retry Orchestration · Proc. ACM Program. Lang. 2023 |
Distributed systems › distributed programming
actor model |
0.7 | 1 | 2023 | Reliable Actors with Retry Orchestration · Proc. ACM Program. Lang. 2023 |
Distributed systems
fault tolerance |
0.7 | 1 | 2023 | Reliable Actors with Retry Orchestration · Proc. ACM Program. Lang. 2023 |
Methods — techniques the papers use, named apart from their topics
tail calls · 1.3process calculus · 1.3
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2023 | Reliable Actors with Retry OrchestrationabstractCloud developers have to build applications that are resilient to failures and interruptions. We advocate for a fault-tolerant programming model for the cloud based on actors, retry orchestration, and tail calls. This model builds upon persistent data stores and message queues readily available on the cloud. Retry orchestration not only guarantees that (1) failed actor invocations will be retried but also that (2) completed invocations are never repeated and (3) it preserves a strict happen-before relationship across failures within call stacks. Tail calls can break complex tasks into simple steps to minimize re-execution during recovery. We review key application patterns and failure scenarios. We formalize a process calculus to precisely capture the mechanisms of fault tolerance in this model. We briefly describe our implementation. Using an application inspired by a typical enterprise scenario, we validate the functional correctness of our implementation and assess the impact of fault preparedness and recovery on performance. Olivier Tardieu, David Grove, Gheorghe-Teodor Bercea, Paul Castro, Jaroslaw Cwiklik, Edward A. Epstein |
Proc. ACM Program. Lang. | 5 |