# Reading from 'old' versions

**URL:** https://forums.foundationdb.org/t/reading-from-old-versions/3576
**Category:** Using FoundationDB
**Created:** [October 4, 2022, 1:52pm UTC](https://forums.foundationdb.org/t/reading-from-old-versions/3576 "2022-10-04T13:52:18Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![hbs](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/hbs/32/1419_2.png) [@hbs](https://forums.foundationdb.org/u/hbs)
#### Post date: [October 4, 2022, 1:52pm UTC](https://forums.foundationdb.org/t/reading-from-old-versions/3576/1 "2022-10-04T13:52:18Z")

</div>

Hi, from time to time when some of the storage servers are lagging, read attempts fail with an error 1037 (process\_behind).

For our use case it is totally ok to read old versions of data, so my question is, is there a way to indicate the FDB client (Java API), that we want to read the specified range regardless of its version?

---

<div class="post-metadata">

### Author: ![jzhou](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/jzhou/32/445_2.png) [@jzhou](https://forums.foundationdb.org/u/jzhou)
#### Post date: [October 7, 2022, 3:10am UTC](https://forums.foundationdb.org/t/reading-from-old-versions/3576/2 "2022-10-07T03:10:28Z")

</div>

The short answer is no.

The storage works by checking read version with `waitForVersion()` for a request, and will return `process_behind` error there. To bypass this check, a new option needs to be added to the request so that the behavior of `waitForVersion()` can be different. I don’t think this super hard, but does require many client-side and binding changes.

---

<div class="post-metadata">

### Author: ![hbs](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/hbs/32/1419_2.png) [@hbs](https://forums.foundationdb.org/u/hbs)
#### Post date: [October 7, 2022, 8:26am UTC](https://forums.foundationdb.org/t/reading-from-old-versions/3576/3 "2022-10-07T08:26:13Z")

</div>

Thanks for your answer.

In the Java bindings, calling snapshot() on a Transaction will return a ReadTransaction instance which has a setVersion method. Would forcing a version number using this method achieve the correct behavior, i.e. send that specific version as the expected one and therefore have waitForVersion consider it?

---

<div class="post-metadata">

### Author: ![alexmiller](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alexmiller/32/326_2.png) [@alexmiller](https://forums.foundationdb.org/u/alexmiller)
#### Post date: [October 7, 2022, 9:22am UTC](https://forums.foundationdb.org/t/reading-from-old-versions/3576/4 "2022-10-07T09:22:08Z")

</div>

You can set an arbitrary read version on a transaction, and FDB will try to honor it. But the challenge here is that you’d have to guess the right read version. You could try fetching a read version, subtracting 2,000,000, and thus letting a process be 2 seconds behind as you’re saying you’d like a 2 second stale read result. But it doesn’t really satisfy your exact request of “give me the most recent data you immediately have”.

I think I was talking with @andrew.noyes about this a year or two ago, and he pointed out that the storage server side of implementing this request is a bit more complicated, as it has to make sure that the “most recent version” that it offers to a client is something that’s promised to kept after a recovery, and not literally the most recent version as that would expose to-be-rolled-back data to clients.

---

<div class="post-metadata">

### Author: ![hbs](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/hbs/32/1419_2.png) [@hbs](https://forums.foundationdb.org/u/hbs)
#### Post date: [October 7, 2022, 12:39pm UTC](https://forums.foundationdb.org/t/reading-from-old-versions/3576/5 "2022-10-07T12:39:51Z")

</div>

I could keep track of the last seen read version in a successful getRange, assuming we have sufficient reads this should converge towards the actual current “valid” read version that can be used. So the flow would be to attempt a getRange without specifying a read version and if an error 1037 is encountered, retry the getrange with the last seen read version so we can serve stale data instead of failing.
