Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-36979

Aborting a transaction must abort WUOW before releasing locks.

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 4.0.4, 4.1.4
    • Replication
    • None
    • Fully Compatible
    • ALL
    • v4.0
    • Repl 2018-10-08
    • 62

    Description

      When we abort a transaction from the expired transactions reaper (or otherwise outside the transaction), we call code in ~TxnResources which calls _locker->endWriteUnitOfWork, then _recoveryUnit->abortWriteUnitOfWork. In the usual case of allowing a WUOW to go out of scope, we call recoveryUnit->abortUnitOfWork and then lockState->endWriteUnitOfWork. The second order is correct. Calling endWriteUnitOfWork releases locks, but some of the internal machinery of abortUnitOfWork may require resources protected by those locks. In particular, in BF-10436, aborting an insert() expected the WiredTigerRecordStore to be available, but a concurrent dropCollection caused it to be destroyed.

      Note the incorrect same ordering is used in ~OplogSlotReserver.

      Attachments

        Activity

          People

            matthew.russotto@mongodb.com Matthew Russotto
            matthew.russotto@mongodb.com Matthew Russotto
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: