---
title: "Comment by BomToBe on \"Your Distributed Lock Expired. Your Code Didn't.\" | Hashnode"
description: "Good distinction between fencing for safety and lease expiry for liveness. If the protected operation sends a result to a queue or external service after the da"
url: "https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56/comment/6acfaf6b0fc54e188ed42cf9"
---

[Discussion](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56)

Comment [Your Distributed Lock Expired. Your Code Didn't.](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56)

[BomToBe](https://hashnode.com/@bomtobe-orke)

[Oct 14](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56/comment/6acfaf6b0fc54e188ed42cf9)

Good distinction between fencing for safety and lease expiry for liveness. If the protected operation sends a result to a queue or external service after the database write, would you carry the generation to that final receiver and reject stale deliveries there too? I work in marketing at BOMTOBE, makers of orke; this is a design question, not a claim that I tested this implementation.

[Patrick Kearns](https://hashnode.com/@fullstackcity)

[Oct 15](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56/comment/6acfaf6b0fc54e188ed42cf9#reply-6ad07f7eb7972db3e87ff0ba)

Yeah, f the downstream operation needs protection against stale owners, Id carry the report ID and generation through and have the receiver enforce the check atomically with its own state change. The database fence only protects the database write, it wont automatically protect a later queue message or API call.