---
title: "Comment by Ahmet Özel on \"Fencing Tokens in .NET\" | Hashnode"
description: "The write-boundary requirement is the part many lock implementations miss. If the final side effect is an object store, message broker, or third-party API that"
url: "https://hashnode.com/posts/fencing-tokens-in-net/6a723685183addc17be0b86b/comment/6a7372845fe4af08364bdf58"
---

[Discussion](https://hashnode.com/posts/fencing-tokens-in-net/6a723685183addc17be0b86b)

Comment [Fencing Tokens in .NET](https://hashnode.com/posts/fencing-tokens-in-net/6a723685183addc17be0b86b)

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Aug 5](https://hashnode.com/posts/fencing-tokens-in-net/6a723685183addc17be0b86b/comment/6a7372845fe4af08364bdf58)

The write-boundary requirement is the part many lock implementations miss. If the final side effect is an object store, message broker, or third-party API that cannot atomically compare the generation, the fencing token is only evidence, not enforcement. One practical pattern is to write through a small authoritative service or database row that records the highest accepted token and an idempotency key before emitting the external effect. I would test delayed requests explicitly by holding token N, committing N+1, then releasing N and proving every downstream path rejects or deduplicates it.

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

[Aug 6](https://hashnode.com/posts/fencing-tokens-in-net/6a723685183addc17be0b86b/comment/6a7372845fe4af08364bdf58#reply-6a74f47729c331c8cf10da5d)

A great way to test it!

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Aug 21](https://hashnode.com/posts/fencing-tokens-in-net/6a723685183addc17be0b86b/comment/6a7372845fe4af08364bdf58#reply-6a87e22f915273a59339613a)

Thanks. I like turning the stale-holder case into a deterministic integration test because it catches token-propagation gaps, not just lock acquisition bugs. The key assertion is that token N causes no external side effect after N+1 has been accepted, including retries and delayed messages.