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

Aborting a transaction must abort WUOW before releasing locks.

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.0.4, 4.1.4
    • Affects Version/s: None
    • Component/s: Replication
    • Labels:
    • Fully Compatible
    • ALL
    • v4.0
    • Repl 2018-10-08
    • 62

      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.

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