Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NonIsolatedPlan should maintain its own transactions #68

Open
4 tasks
apkar opened this issue Feb 7, 2019 · 0 comments
Open
4 tasks

NonIsolatedPlan should maintain its own transactions #68

apkar opened this issue Feb 7, 2019 · 0 comments
Milestone

Comments

@apkar
Copy link
Contributor

apkar commented Feb 7, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants