Refactor OEntityStore level transactions #192
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A transaction is active/usable from our point of view only if it is in a BEGUN state
It seems that we should always use rollback(force = true), otherwise the session may get a broken state and become unusable.
The previous implementation created a session on every access to the sequence (get, increment, etc.) The new implementation creates a new session only when both the sequence has not been created yet and the current session has an active transaction. Also, the new implementation makes sure that the sequence is created right away and not lazily.
…that creates sessions It leaves less room for bugs because the client's code does not have to deal with closing the new session and reactivating the previous one.
1. The transaction lifecycle is tightly bound to the ODatabaseSession lifecycle. Transactions start and finish with sessions. 2. Transaction can be read-only. 3. Transactions validate their state on every operation. 4. OEntityStore does not let create several transactions on a single thread. 5. Get rid of the code for nested/embedded transactions
kirillvasilenko
changed the title
Sessions should not be accessible for client code. They are implementation details and very fragile. Never touch a session.
# Conflicts: # entity-store/src/main/kotlin/jetbrains/exodus/entitystore/orientdb/query/OQueryExecution.kt
…ctive session on the current thread
…leBase. count() and roughCount() behave as size() and roughSize() now. This countExecutor activated the session on another thread that caused a bunch of concurrency related bugs. Decided not to calculate anything in the background until it is necessary.
not to access ODatabaseSession directly, rewrite blob-related code 1. OVertexEntity should never access ODatabaseSession directly. 2. Blob-related logic does not create additional/artificial/extra records to handle blobs. Now we use ORecordBytes to store the actual data. It is a special Oreint data type for such use-cases.
…her part of the application
…nto fix-otransaction-commit-flush
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
EntityStore level transactions are rewritten
Changed Blob implementation
Use ORecordBytes to store blobs - a special Orient type for binary data.
Deleted OEnvironment and Co
Because its existence does not make sense.