[SERVER-64982] Extended lack of availability caused by transactions Created: 28/Mar/22  Updated: 06/Dec/23

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

Type: Bug Priority: Major - P3
Reporter: Louis Williams Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: former-storex-namer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on WT-10958 Session API to roll-back a transactio... Open
depends on WT-8848 Add API to roll back and indicate tha... Closed
Related
related to DOCS-16283 [SERVER] Improve note about multi-doc... Closed
related to SERVER-61251 Ensure long running storage engine op... Backlog
is related to SERVER-83186 Writers can get stuck in cache evicti... Open
is related to WT-9035 Asynchronously roll back transactions... Closed
is related to SERVER-77172 "abortExpiredTransactions" thread can... Backlog
Assigned Teams:
Storage Execution
Operating System: ALL
Sprint: Execution EMEA Team 2023-07-24
Participants:
Linked BF Score: 8

 Comments   
Comment by Josef Ahmad [ 31/Jul/23 ]

After consulting with sulabh.mahajan@mongodb.com, who's looking into a broader class of WT cache pressure-related problems in the MongoDB server, I've decided to mark this ticket as dependent on WT-10958. That WT ticket would allow MongoDB to efficiently roll back the transactions that have been blocking eviction, covering the case of an offending transaction that's been sitting idle for most of its time.
 
Note that this ticket was initially marked as dependent on WT-8848; however, that WT ticket ended up implementing a different approach which doesn't meaningfully apply to SERVER-64982 any longer.
 
Based on the conversation in this server ticket, I've also filed DOCS-16283 to improve the documentation around multi-doc transactions during periods of untenable WT cache pressure.

Comment by Yujin Kang Park [ 27/Jun/23 ]

connie.chen@mongodb.com, not really. SERVER-61909 changes the retry behaviour of a single large transaction after we get a WT_ROLLBACK error, the problem described here is more about the fact that a transaction may occupy a large portion of the cache, and not make any more calls into the WT api, and thus not get rolled back, blocking progress for other transactions. 

Comment by Connie Chen [ 26/Jun/23 ]

yujin.kang@mongodb.com was this work already covered as part of https://jira.mongodb.org/browse/SERVER-61909 ?

Generated at Thu Feb 08 06:01:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.