Sorry, I also missed that you quoted this specific bit about eagerly requesting a new snapshot. Currently the code will just react to the transaction expiring, then wait till it acquires a new snapshot if “restart_tx” is set (which can take a couple of milliseconds on a FoundationDB cluster that is deployed across multiple AZs in a cloud Region) and then proceed.
Adam > On Jul 15, 2020, at 6:54 PM, Adam Kocoloski <kocol...@apache.org> wrote: > > Right now the code has an internal “restart_tx” flag that is used to > automatically request a new snapshot if the original one expires and continue > streaming the response. It can be used for all manner of multi-row responses, > not just _changes. > > As this is a pretty big change to the isolation guarantees provided by the > database Bob volunteered to elevate the issue to the mailing list for a > deeper discussion. > > Cheers, Adam > >> On Jul 15, 2020, at 11:38 AM, Joan Touzet <woh...@apache.org> wrote: >> >> I'm having trouble following the thread... >> >> On 14/07/2020 14:56, Adam Kocoloski wrote: >>> For cases where you’re not concerned about the snapshot isolation (e.g. >>> streaming an entire _changes feed), there is a small performance benefit to >>> requesting a new FDB transaction asynchronously before the old one actually >>> times out and swapping over to it. That’s a pattern I’ve seen in other FDB >>> layers but I’m not sure we’ve used it anywhere in CouchDB yet. >> >> How does _changes work right now in the proposed 4.0 code? >> >> -Joan >
