# Transaction Too Old error when using a common read version with multiple client connections **URL:** \ **Category:** Using Layers\ **Created:** [December 8, 2020, 5:00pm UTC](https://forums.foundationdb.org/t/transaction-too-old-error-when-using-a-common-read-version-with-multiple-client-connections/2475 "2020-12-08T17:00:23Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![TomG](https://avatars.discourse-cdn.com/v4/letter/t/ac8455/32.png) [@TomG](https://forums.foundationdb.org/u/TomG)\ **Post date:** [December 8, 2020, 5:00pm UTC](https://forums.foundationdb.org/t/transaction-too-old-error-when-using-a-common-read-version-with-multiple-client-connections/2475/1 "2020-12-08T17:00:24Z")
Our application splits up read requests for multiple range scans to use multiple separate processes that each issue their own separate read requests to improve our parallelization for reads. When we try to use the same read version for each of the individual read requests, we immediately encounter transaction\_too\_old error, error code 1007. The Coordinator process calls `get_read_version()` and then sends the read version number to the Read Worker processes, which will create a transaction and call `set_read_version()` before calling `get_ranges()` and send the results from the range scan back to the coordinator. The `get_ranges()` requests all fail immediately with error code 1007. The elapsed time between the initial call to `get_read_version()` and the `get_ranges()` request is single digit milliseconds. Every range scan fails every time. Is a read version tied to an individual client connection or any other reason why multiple client connections cannot use the same read version? Currently using the Rust foundationdb-0.4.2 crate for the client, on linux and testing this locally with the memory storage engine. ---
**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:** [December 9, 2020, 12:06am UTC](https://forums.foundationdb.org/t/transaction-too-old-error-when-using-a-common-read-version-with-multiple-client-connections/2475/2 "2020-12-09T00:06:23Z")
The read version you receive from one client should be usable from any other, so long as you use it on the same cluster in a timely manner. There are possibly some concerns around the ability for ratekeeper to throttle your traffic (it typically does this using the `get_read_version` request), but if you aren’t saturating the cluster it should work ok. One thing you could try as an experiment is to get a read version in a transaction on your worker processes to compare to the one you are receiving from the coordinator process. If they are very different, that would be telling. It would also be interesting if you also saw the same errors on transactions that fetched their own read versions. ---
**Author:** ![Daniel-B-Smith](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/daniel-b-smith/32/743_2.png) [@Daniel-B-Smith](https://forums.foundationdb.org/u/Daniel-B-Smith)\ **Post date:** [December 9, 2020, 5:42pm UTC](https://forums.foundationdb.org/t/transaction-too-old-error-when-using-a-common-read-version-with-multiple-client-connections/2475/3 "2020-12-09T17:42:55Z")
Thanks for the response! That was my understanding as well. Tom played around with things and noticed that everything worked fine as long as we called `get_read_version()` at least once in the process. Our child workers only use read versions provided to them. It seems that the client is completely unusable until you call `get_read_version()` (directly or indirectly) at least once. Arguably, we’re holding it wrong, but it would be nice to at least document this rough edge. I’m happy to file a GitHub issue. For reference, the code that is biting us is here: [https://github.com/apple/foundationdb/blob/master/fdbclient/DatabaseContext.h#L249](https://github.com/apple/foundationdb/blob/master/fdbclient/DatabaseContext.h#L249) ---
**Author:** ![alloc](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alloc/32/9_2.png) [@alloc](https://forums.foundationdb.org/u/alloc)\ **Post date:** [December 9, 2020, 6:27pm UTC](https://forums.foundationdb.org/t/transaction-too-old-error-when-using-a-common-read-version-with-multiple-client-connections/2475/4 "2020-12-09T18:27:26Z")
I wonder if this is something to do with the Rust crate, which is a third-party client library not supported directly by the FoundationDB project. The C client should be calling get read version if you don’t do it yourself, so that’s somewhat fishy. I suppose it’s also possible that, say, the integer is being incorrectly passed from Rust to C somehow. But that’s just speculation. ---
**Author:** ![Daniel-B-Smith](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/daniel-b-smith/32/743_2.png) [@Daniel-B-Smith](https://forums.foundationdb.org/u/Daniel-B-Smith)\ **Post date:** [December 9, 2020, 6:30pm UTC](https://forums.foundationdb.org/t/transaction-too-old-error-when-using-a-common-read-version-with-multiple-client-connections/2475/5 "2020-12-09T18:30:20Z")
To be clear, we are calling `set_read_version()` on every single transaction in this process, all of which are read only. As the code was originally written, `get_read_version()` was never called even indirectly, and the FDB client chokes if you do that. In particular, when we call `get_read_version()` as part of startup, everything works just as expected. ---
**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:** [December 9, 2020, 8:50pm UTC](https://forums.foundationdb.org/t/transaction-too-old-error-when-using-a-common-read-version-with-multiple-client-connections/2475/6 "2020-12-09T20:50:30Z")
Oh right, I remember now that this was added as part of some other feature in 6.2 it looks like: >