A distributed lock for scheduled tasks ensuring at-most-once execution across multiple nodes.
ShedLock is a Java library that provides distributed locking for scheduled tasks, ensuring they execute at most once across multiple nodes in a cluster. It solves the problem of duplicate task execution in horizontally scaled applications by using an external store (like a database or Redis) to coordinate locks. Tasks are annotated with `@SchedulerLock`, and if a lock is held by one node, other nodes skip execution rather than waiting.
Java developers building Spring Boot, Micronaut, or Quarkus applications with scheduled tasks (e.g., cron jobs) that need to run reliably in clustered or cloud environments. It's especially useful for teams deploying microservices where multiple instances might trigger the same scheduled logic.
Developers choose ShedLock for its simplicity, robust integration with popular frameworks, and support for numerous lock providers. Unlike full distributed schedulers, it focuses solely on preventing concurrent execution, making it lightweight and easy to adopt without overhauling existing scheduling setups.
Distributed lock for your scheduled tasks
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Supports over 30 backends including JDBC, Redis, Mongo, and cloud services, making it adaptable to diverse infrastructures without vendor lock-in.
Works seamlessly with Spring, Micronaut, CDI (Quarkus), and standalone Java, minimizing framework dependencies and easing adoption.
Ensures scheduled tasks run at most once per cluster using distributed locks, preventing duplicate processing in scaled deployments.
Just annotate methods with @SchedulerLock and configure a lock provider, requiring minimal code changes to existing scheduled tasks.
Lacks job orchestration features like retries, dependencies, or dynamic scheduling; the README explicitly states it's just a lock, not a scheduler.
Duplicate execution can occur if tasks exceed lockAtMostFor or clocks are unsynchronized, as noted in the caveats section, requiring careful configuration.
Requires setting up and maintaining an external store (e.g., database tables for JDBC), adding operational complexity compared to in-memory solutions.
Some lock providers have reliability issues; for example, the README warns that Memcached may release locks prematurely, and R2DBC support is experimental.