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.