[SERVER-15944] Make single-update write conflict path same as multi-update Created: 04/Nov/14 Updated: 18/Sep/15 Resolved: 06/Feb/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency, Sharding |
| Affects Version/s: | 2.8.0-rc0 |
| Fix Version/s: | 3.0.0-rc9, 3.1.0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Greg Studer | Assignee: | Eliot Horowitz (Inactive) |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Backport Completed: | |||||||||
| Participants: | |||||||||
| Description |
|
The introduction of WriteConflictExceptions adds another lock-reacquistion path for certain storage engines. Because sharding and replication code need to recheck invariants on most lock reacquisition, this increases the number of places that need to be audited for correct behavior on reacquiring the lock. WriteConflictExceptions also break the executor model, in that successfully running an update/delete query now requires a retry loop which is easy to forget. Some sort of encapsulation of the invariants that need to be checked every time locks are reacquired would make it possible to generically run an executor with retry whether the lock reacquisition was due to old-style yielding or new-style WriteConflictException retries. |
| Comments |
| Comment by Githook User [ 06/Feb/15 ] |
|
Author: {u'username': u'erh', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}Message: (cherry picked from commit d408142cdc981a005db4ae4969c85137a1e15e4a) |
| Comment by Githook User [ 06/Feb/15 ] |
|
Author: {u'username': u'erh', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}Message: |