I said a bunch of this on IRC also but Adam has it. further operations within
the 'expired' txn just fail. we recognise that and start a new one. In the
_changes case, we'd send a last_seq row and end the request, but this isn't
going to be a great answer (at least, not a backward compatible
Bah, our “cue”, not our “queue” ;)
Adam
> On Mar 7, 2019, at 7:35 AM, Adam Kocoloski wrote:
>
> Hi Garren,
>
> In general we wouldn’t know ahead of time whether we can complete in five
> seconds. I believe the way it works is that we start a transaction, issue a
> bunch of reads, and after
Hi Garren,
In general we wouldn’t know ahead of time whether we can complete in five
seconds. I believe the way it works is that we start a transaction, issue a
bunch of reads, and after 5 seconds any additional reads will start to fail
with something like “read version too old”. That’s our
I agree that option A seems the most sensibile. I just want to understand
this comment:
>> A _changes request that cannot be satisfied within the 5 second limit
will be implemented as multiple FoundationDB transactions under the covers
How will we know if a change request cannot be completed in
Hi,
Given that option A is the behaviour of feed=continuous today (barring the
initial whole-snapshot phase to catch up to "now") I think that's the right
move. I confess to not reading your option B too deeply but I was there on IRC
when the first spark was lit. We can build some sort of
Hi all, as the project devs are working through the design for the _changes
feed in FoundationDB we’ve come across a limitation that is worth discussing
with the broader user community. FoundationDB currently imposes a 5 second
limit on all transactions, and read versions from old transactions
