# Understanding "Watches"

**URL:** <https://forums.foundationdb.org/t/understanding-watches/903>\
**Category:** Using FoundationDB\
**Created:** [November 26, 2018, 5:28pm UTC](https://forums.foundationdb.org/t/understanding-watches/903 "2018-11-26T17:28:09Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![ajbeamon](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/ajbeamon/32/13_2.png) [@ajbeamon](https://forums.foundationdb.org/u/ajbeamon)\
**Post date:** [November 26, 2018, 6:43pm UTC](https://forums.foundationdb.org/t/understanding-watches/903/2 "2018-11-26T18:43:23Z")

</div>

> [@MansurAshraf](#):
>
> It seems like I cannot put watch on parent subspace (example\_service in this case). I have to put watch on exact key  
> `example\_service,127.0.0.1

Watches are only supported on individual keys, not on ranges. If you want to track changes to a range, one way is to have a separate key that you modify every time the range gets modified. This key could store a value that’s incremented with atomic adds or that includes a versionstamp. Then you could watch this key to know when the range is updated. There’s a good bit of discussion about this in [this thread](https://forums.foundationdb.org/t/changefeeds-watching-and-getting-updates-on-ranges-of-keys/511).

> [@MansurAshraf](#):
>
> In java binding result of the watch in a Future, and watch is trigger when future completes. Which means that I only get notified of the first change on that key. In my usecase I want to get notified everytime a new ip in added under example\_service. Not sure if its possible to accomplish that?

The contract is a little different than this. Instead of the first change, you’ll be notified when the key has changed, assuming it stays changed. It’s possible the key may have undergone multiple changes by the time you are notified, and it’s also possible in the case of an ABA update (one where the value changes from A to B and then back to A) that you may not be notified at all. If you use atomic add or versionstamps as I described above, though, then you don’t have to worry about the ABA problem.

In order to be notified about future changes after a watch fires, you’ll want to set a new watch in the same transaction as the one where you read the range of keys being watched.

> [@MansurAshraf](#):
>
> Finally, to mimic this example on my laptop I had two different transaction, one starting the watch and second triggering the watch by updating the key. This doesnt seem to work as the future from the watch never completes. Only way i got it to work is when both watch is created and key is updated in the same transaction. How would this work when in real application when watch and update will happen on different machines?

The transaction that creates a watch needs to be committed in order for the watch to be set. A watch that isn’t committed can only be triggered by modifications that happen in the same transaction as the watch. Is your watch transaction being committed?

---

_[View the full topic](https://forums.foundationdb.org/t/understanding-watches/903)._