Based on what I understand from the FDB Java Binding APIs, for a getRange() query that can potentially run over 5 seconds and encounter the “transaction too old” exception, I can capture this transaction exception with code 1007, https://apple.github.io/foundationdb/api-error-codes.html, and create a new transaction and then set the new query range that starts from the last key before the transaction. With this mechanism, I can continue the long-range scan.
I am trying to look into the Record Layer Java Library on how it exposes systematically the APIs (with continuations) and composable iterators (or cursors), so that I can compose iterator-based pipeline processing for the key-value retrieved from the FDB getRange() queries.
In the FQA section, https://github.com/FoundationDB/fdb-record-layer/blob/master/docs/FAQ.md, I see the statement “All streaming operations in the Record Layer support continuations… so restarting the same operation with a new transaction and a continuation can allow the operation to continue where it left off.”
My questions are:
(1)does the record layer provide the APIs that handle “restarting the same operation with the new transaction”? if so, can I get the link to the code in the record layer that handle this?
(2) or the application will need to capture the exception, and start a new transaction, along with the “continuation” object retrieved from the failed transaction? If so, how will the application code look like?
(3) With iterator (or cursor) chaining in a processing pipeline, if during one of the iterators processing, transaction becomes too old and the exception gets raised, and transaction gets restarted (either by record layer or by application), how can the remaining chained iterators (cursors) be resumed after the transaction gets restarted? My understanding is that an iterator (may be cursor as well) is tied to a transaction object and no way to resume from a new transaction.