[SERVER-63813] Allow transactions and snapshot reads on capped collections Created: 18/Feb/22  Updated: 21/Jul/23

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Judah Schvimer Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-47824 Ban transaction snapshot reads on cap... Closed
is related to SERVER-16049 Replicate capped collection deletes e... Closed
is related to SERVER-53965 Add option to use transactions with c... Closed
is related to SERVER-47574 Ban non-transaction snapshot reads on... Closed
Assigned Teams:
Storage Execution
Participants:

 Description   

This is effectively reopening SERVER-52965 now that SERVER-16049 is complete and undoing SERVER-47824 and SERVER-47574. We could certainly add these two features separately. As we want to use snapshot reads and transactions internally to support other features, having capped collections be less "special" will make this easier.



 Comments   
Comment by Louis Williams [ 04/Mar/22 ]

The relevant detail in that comment is:

The behavior of an operation against a capped collection may differ across replica set members, where it can succeed on one member and fail on another, crashing the failing member.

As Judah observed, this is no longer a problem because we replicate deletes in the oplog, so all nodes have the exact same contents.

capped collections are still problematic with transactions because they only allow one operation at a time because they enforce insertion order with a MODE_X collection lock, which we cannot hold in transactions.

This isn't accurate. We take the "metadata lock", not the collection lock, but this will cause transactions on capped collections to serialize themselves, since this lock is held for the duration of the WUOW. If we're okay with that behavior, we need to be careful not to introduce deadlocks. Currently, the metadata lock acquisition is not interruptible. That is, it doesn't use the constructor that accepts an opCtx. This is a relatively easy change.

Comment by Wenbin Zhu [ 03/Mar/22 ]

I did some testing and it looks like we don't even allow doing writes on capped collection in a transaction. I think since capped collection cannot be sharded (no out-of-order events), maybe we can identify the capped collections when receiving the event and not do transaction for these collection. BTW are we able to cut scope for capped collections in 6.0?

Generated at Thu Feb 08 05:58:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.