[SERVER-18523] Make RecoveryUnit a decoration on OperationContext Created: 18/May/15 Updated: 26/Apr/19 Resolved: 26/Apr/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Andy Schwerin | Assignee: | Geert Bosch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | Storage NYC 2019-05-06 |
| Participants: |
| Description |
|
Rather than have three virtual functions implemented on OperationContextImpl, we should make RecoveryUnit a decoration on the OperationContext, accessed via RecoveryUnit::get(OperationContext*). |
| Comments |
| Comment by Geert Bosch [ 26/Apr/19 ] |
|
As OperationContextImpl no longer exists, this ticket seems no longer required. The issues in making RecoveryUnit a decoration still exist. |
| Comment by Andy Schwerin [ 31/Aug/15 ] |
|
geert.bosch, I do not understand your comment, above. It's not essential that we do this soon, but getting RecoveryUnit off of OperationContextImpl is an important step in eliminating OperationContextImpl as a type distinct from OperationContext and OperationContextNoop. This, in turn, is important for making OperationContext work uniformly in mongos and mongod. |
| Comment by Geert Bosch [ 31/Aug/15 ] |
|
I tried doing this, but this doesn't actually work well as the RecoveryUnitState, which tracks whether an operation is in a WriteUnitOfWork and has to commit or abort, is actually part of the OperationContext (_ruState). |