IllegalStateException due to out-of-order MVVs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Akiban Persistit |
Fix Released
|
High
|
Peter Beaman |
Bug Description
Persistit r372
An IllegalStateExc
I was able to catch this with a breakpoint and diagnose it. The MVV contains a version with handle B and the storeVersion is attempting to add a new version A < B. If B were anything but an ABORTED transaction, this would be a serious corruption. However, B has been ABORTED, and therefore can be pruned.
The code path in Exchange#
1. Prune the MVV
2. Test for ww-dependencies
3. Add the new version
At step 1, during the prune operation, B was still UNCOMMITTED.
At step 2, during the ww-dependency check, B had become ABORTED.
At step 3, there is no check in storeVersion for whether B is still UNCOMMITTED or ABORTED, but merely a test on whether B > A to trigger the ISE.
The reason this doesn't happen more often is that B must abort after step 1 but before step 2, and this is a small time window.
Marking the HIGH because it affects our testing, but given the use cases in the field is (a) unlikely, and (b) does not cause data loss.
Note that although the code that causes this bug is in trunk, it has never been released.
Related branches
- Nathan Williams: Approve
-
Diff: 231 lines (+116/-51)3 files modifiedsrc/main/java/com/persistit/Exchange.java (+74/-50)
src/main/java/com/persistit/MVV.java (+2/-1)
src/main/java/com/persistit/exception/VersionsOutOfOrderException.java (+40/-0)
Changed in akiban-persistit: | |
assignee: | nobody → Peter Beaman (pbeaman) |
milestone: | none → 3.1.8 |
description: | updated |
Changed in akiban-persistit: | |
status: | Confirmed → Fix Committed |
Changed in akiban-persistit: | |
status: | Fix Committed → Fix Released |