Transaction reads should not interfere with add/update/delete#3163
Transaction reads should not interfere with add/update/delete#3163Cole-Greer merged 3 commits intoapache:3.7-devfrom
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## 3.7-dev #3163 +/- ##
=============================================
+ Coverage 76.14% 76.20% +0.06%
- Complexity 13152 13286 +134
=============================================
Files 1084 1091 +7
Lines 65160 67645 +2485
Branches 7285 7371 +86
=============================================
+ Hits 49616 51552 +1936
- Misses 12839 13362 +523
- Partials 2705 2731 +26 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Changed TinkerElementContainer to no longer consider element reads as being 'used in a transaction' which should be reserved for element add/update/delete only. This is appropriate for TinkerTransactionGraph because the isolation level is 'read committed'. With this isolation level, we do not need to protect against 'unrepeatable reads' or 'phantom reads'. Prior to this change, a read-only thread could cause a 'Conflict: element modified in another transaction' error in a separate thread which was attempting add/drop/update.
andreachild
force-pushed
the
TINKERPOP-3142-readTransactions
branch
from
85d9fc6 to
b84a60b
Compare
|
@vkagamlyk would appreciate a review of this fix, thanks! |
|
Thank you! VOTE + 1 after adding assertions to tests |
…sts. Added additional reader thread.
|
VOTE +1 pending CHANGELOG entry, and ideally some updates to reference doc to emphasize that non-repeatable reads and phantom reads are not protected at our isolation level. |
…nd phantom reads are not prevented.
Thanks, added changelog and updated semantics docs. |
|
VOTE +1. In my opinion the documentation has always been explicit regarding what isolation level we guarantee. I'm not opposed to adding an extra sentence or 2 stating that non-repeatable reads and phantom reads are not covered, but I don't believe it is necessary. |
5 participants
https://issues.apache.org/jira/browse/TINKERPOP-3142
Changed
TinkerElementContainerto no longer consider element reads as being 'used in a transaction' which should be reserved for element add/update/delete only. This is appropriate forTinkerTransactionGraphbecause the isolation level is 'read committed'. With this isolation level, we do not need to protect against 'unrepeatable reads' or 'phantom reads'.Prior to this change, a read-only thread could cause a 'Conflict: element modified in another transaction' error in a separate thread which was attempting add/drop/update.