Check if XT1 Node is "Stale" (not caught up with latest transactions) while Querying

Users
1

I have an XT Node running as an ECS Instance which is populated through a Kafka Transaction Log. However when this node restarts i.e. a new instance of it is created, it is initially catching up on Transactions so returns “stale” date on reads (writes timeout since other transactions are being executed).

An example would be I have an API that checks for the existence of document A for user 1. When I create the document A for user 1, its written to the transaction log and indexed. So the XT node is able to return the document on reads. However when the node restarts, the transaction to create document A for user 1 might still not be performed, so when the API queries XT it would get an “empty” search result back indicating that there is no such document A for user:1 and the API would return an inaccurate value.

So was wondering what might be possible mitigations to the above? One mitigation would be if while querying for data I could check that the node is “caught up” (check if a certain transaction has been executed, or check number of transactions waiting to be executed), so was wondering if checking for data freshness while querying data is possible?

This is with XT v1 :slight_smile:

2

Hey @Sh4d0w you have a few options:

  1. await-tx (blocking) takes as its argument the output of submit-tx (for basic read-your-writes)
  2. sync (blocking) will call latest-submitted-tx (which checks the log for the freshest transactions available) and then runs await-tx
  3. observe the difference between latest-completed-tx (which is local to a given node) and latest-submitted-tx (which is common across the cluster) to establish safe bounds for a staleness/lag metric that satisfies your consistency requirements

Hope that helps :slightly_smiling_face:

Jeremy

3

That is useful. Thank you for sharing. However I was wondering if it would be possible to configure this on the Server Image itself rather than being dependent on the client to check if the Node has caught up with latest transactions?

So the XT Server itself would reject requests (even reads, since it would already fail writes due to waiting for a transaction) while the node is “behind” transactions?

1 Like
4

The XT1 API is primarily designed for in-process usage - the idea being that you have complete control over any subsequent network API you want to provide to your client(s). The official HTTP/client API design therefore simply attempts mirrors this.

Adding some optional functionality to make things behave how you describe is likely possible, but it’s hard to get such designs correct without a clear understanding of the serialization levels you are hoping to achieve (e.g. how do you want to define & enforce “behind”). However, you could consider forking the HTTP server module to implement your desired semantics.

I would be happy to help dig into your use case and priorities if it could help at all, feel free to message: hello@xtdb.com