Merge lp:~pbeaman/akiban-persistit/fix-1058650-ISE-out-of-order-MVV into lp:akiban-persistit
Status: | Superseded |
---|---|
Proposed branch: | lp:~pbeaman/akiban-persistit/fix-1058650-ISE-out-of-order-MVV |
Merge into: | lp:akiban-persistit |
Diff against target: |
231 lines (+116/-51) 3 files modified
src/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) |
To merge this branch: | bzr merge lp:~pbeaman/akiban-persistit/fix-1058650-ISE-out-of-order-MVV |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Nathan Williams | Approve | ||
Review via email: mp+127340@code.launchpad.net |
This proposal has been superseded by a proposal from 2012-10-02.
Description of the change
Fix bug 1058650 IllegalStateExc
I did not add a unit test since sequencing this is a bit tricky with ThreadSequencer, but I did confirm by running the MixtureTxn1 stress test that instances of retry do occur and yield the correct result.
Part of the implementation is a new VersionsOutOfOr
Note that the assert statement that detects this condition was added only recently, and the condition in which an aborted transaction's version is out-of-sequence with another version must have occurred often and harmlessly before this. The fix chosen here is to prune that version away rather than leaving it since (a) it's an opportune time to prune, and (b) it keeps the ordering logic and assertion simple.
Rare and subtle indeed.
Is this retry loop safe? I'm thinking of something like a prune that really does change the array, so getEncodedSize() != spareSize, and then a failed store. Wouldn't the next call to prune and visit think the array is bigger than it actually is?