[SERVER-33244] Make all lock acquisitions for transactions have 0 second timeout Created: 09/Feb/18  Updated: 29/Oct/23  Resolved: 14/May/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.0.0-rc0

Type: Bug Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Dianna Hohensee (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-34829 Drop pending reaper must not delete t... Closed
depends on SERVER-34372 Drop collection command with majority... Closed
is depended on by SERVER-34726 Deadlock with locally stashed transac... Closed
is depended on by SERVER-34800 The transaction aborter thread should... Closed
Documented
is documented by DOCS-11716 Docs for SERVER-33244: Make all lock ... Closed
Related
is related to SERVER-34951 LockerImpl should invariant against a... Backlog
is related to SERVER-34924 Treat LockTimeout as transient transa... Closed
is related to SERVER-35023 Add server parameter maxTransactionLo... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Storage NYC 2018-03-26, Storage NYC 2018-04-09, Storage NYC 2018-03-12, Storage NYC 2018-04-23, Storage NYC 2018-05-07, Storage NYC 2018-05-21
Participants:
Linked BF Score: 58

 Description   

Txns should do no waiting for locks, they should fail the lock acquisition immediately if there's any conflict. They should also abort the transaction if that happens.



 Comments   
Comment by Githook User [ 14/May/18 ]

Author:

{'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@10gen.com', 'username': 'DiannaHohensee'}

Message: SERVER-33244 All lock acquisitions for transaction operations obey maxTransactionLockRequestTimeoutMillis, which defaults to 0 millis
Branch: master
https://github.com/mongodb/mongo/commit/d12afa4fdda9c6b113e7be3b4d67d757b07b50b5

Comment by Dianna Hohensee (Inactive) [ 03/May/18 ]

Found a bug, made a ticket: SERVER-34829.

Comment by Dianna Hohensee (Inactive) [ 02/May/18 ]

Yup, on it

Comment by Spencer Brody (Inactive) [ 02/May/18 ]

We should make sure that the new parameter has sub-second granularity, at least to the millisecond level.

Comment by Eric Milkie [ 01/May/18 ]

We're going to add a parameter to control the timeout value. The default will be "0 seconds" but in cases of troublesome workloads, an admin will be able to raise the timeout to some higher number of seconds.

Comment by Dianna Hohensee (Inactive) [ 09/Apr/18 ]

Depends on SERVER-34372 to make drop collection finish completely, including the 2-phase-drop part, with majority write concern.

Otherwise, transactions operations will fail with LockConflict due to racing with the background thread doing 2-phase-drop that takes the database lock.

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