| 2012-10-01 16:32:11 |
Peter Beaman |
description |
Persistit r372
An IllegalStateException thrown by MVV.storeVersion due to out-of-order version handles in the MVV occurred during a large stress test run in Stress8txn.
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#storeInternal looks does this:
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. |
Persistit r372
An IllegalStateException thrown by MVV.storeVersion due to out-of-order version handles in the MVV occurred during a large stress test run in Stress8txn.
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#storeInternal looks does this:
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. |
|
