FoundationDB
NonIsolatedPlan should maintain its own transactions
NonIsolatedPlan is used for requests that can't guarantee atomic operations. For example, updates or queries can have predicates that can match too many documents to read within 5 seconds, consequently in one transaction. NonIsolatedPlan splits this task into multiple transactions. The task is checkpointed after each transaction is committed, so in case of failure, the task is retried since the last checkpoint.
NonIsolatedPlan maintains the transactions itself except the first transaction, which is created before metadata was read. The first transaction would be usually read-only transaction until it passed into NonIsolatedPlan, especially RW plan. The only exception is when a new collection is created implicitly. We should maintain the transaction at a single location (function) - that includes creation, retries and commit. We can make this possible by having read-only transactions and splitting collection creation into its own transaction (when we are not in an explicit transaction).
This cleanup needs following subtasks
- [ ] Add read-only transactions - #69
- [ ] Split collection creation into its own transaction - #51
- [ ] Use read-only transactions in places all over query planner
- [ ] NonIsolatedPlan should create a transaction based on the read version of the initial read-only transaction also add conflict range on metadata
