[SERVER-34800] The transaction aborter thread should acquire locks with a 0-second lock acquisition timeout Created: 02/May/18  Updated: 29/Oct/23  Resolved: 15/May/18

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

Type: Bug Priority: Major - P3
Reporter: James Wahlin 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-33244 Make all lock acquisitions for transa... Closed
Related
is related to SERVER-34732 collection drop hangs in test of tran... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Storage NYC 2018-05-07, Storage NYC 2018-05-21
Participants:

 Description   

It is possible for the transaction timeout periodic task to block on aborting a transaction, while attempting to acquire a database lock. The following is one scenario where this can happen:

  1. Two transactions are opened for a given collection
  2. A collection client cursor is opened for each and MODE_IX database and collection locks are acquired
  3. A drop database command is executed which requests a MODE_X database lock. This request is blocked on both transactions MODE_IX lock
  4. After one minute, the transaction timeout periodic task runs:
    1. An attempt is made to abort the first transaction. Transaction resources (locks and WiredTiger transaction) are freed.
    2. killCursors is called to kill the client cursor. The cursor kill attempt requires a MODE_IS lock which is blocked by the MODE_X request. The MODE_X request is still blocked by the second transactions MODE_IX lock.
  5. At this point unless transaction 2 is committed or aborted by the user, it will continue to block the database drop. The transaction timeout periodic runner will not timeout the second transaction as it is blocked on killing cursors for the first transaction.
  6. Additionally the MODE_X lock will block any further user operations on the database.

Performing transaction timeout with a 0-second lock acquisition timeout would address the above scenario. On failing to kill cursors for transaction 1 it would proceed with killing transaction 2. This would unblock the database drop and allow other operations to run.



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

Author:

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

Message: SERVER-34800 The transaction aborter thread uses 0-second lock acquisition timeout for all lock requests
Branch: master
https://github.com/mongodb/mongo/commit/9df77c72447bad5fab1d2b40feda83749b3767db

Comment by James Wahlin [ 02/May/18 ]

We should also consider running the session timeout mechanism with a 0-second lock acquisition timeout as well.

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