[SERVER-53965] Add option to use transactions with capped collections Created: 22/Jan/21  Updated: 18/Feb/22  Resolved: 08/Feb/21

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

Type: New Feature Priority: Major - P3
Reporter: Johnny Shields Assignee: Judah Schvimer
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-63813 Allow transactions and snapshot reads... Backlog
Sprint: Repl 2021-02-08, Repl 2021-02-22
Participants:

 Description   

It seems recent tickets are restricting use of capped collections with transactions, e.g. SERVER-47824. However, it seems that if a user knows what he/she is doing, they should have the option to enable transactions with capped collections for both read and write. Perhaps such option could be disabled by default and required user to set a param on the transaction (allowCappedCollections: true).

My use case: I use a lock collections for my transactions, and upsert documents to it with the scope I want to lock. This lock collection grows indefinitely, and so setting some reasonable size cap (100MB) would be ideal. In practice the locks I would ever write at any one time would never be more than 1MB even in a degenerate scenario, so there is no way the cap is going to affect the transactional integrity of my system in the real world.



 Comments   
Comment by Johnny Shields [ 06/Feb/21 ]

A TTL index will work for my use case, thanks.

Comment by Judah Schvimer [ 01/Feb/21 ]

Hi shields@tablecheck.com,

Thank you for this feature request! We are worried that while some users will understand what they are doing, others won't. We would like to avoid adding a mechanism to the server that users could easily misuse and that would give them incorrect results. Would it be possible to use a TTL index to accomplish your use case? Collections with TTL indexes are supported in transactions and the collection will still truncate itself over time (by time rather than by size, though). We plan to close this ticket "Won't Fix", but first want to ensure that your use case is satisfactorily met. Does this workaround accomplish your goal?

Thank you,
Judah

Comment by Edwin Zhou [ 27/Jan/21 ]

Hi shields@tablecheck.com,

Thanks for providing a detailed description of your improvement and your use case. We're assigning this ticket to the appropriate team to be evaluated against our currently planned work. Updates will be posted on this ticket as they happen.

Best,
Edwin

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