Given a large enough page is created a by a transaction running in WiredTiger, it may get force evicted causing a rollback to be returned to the transaction, the transaction also needs to be the oldest transaction in the system and meet the criteria to be "blocking", see: __wt_txn_is_blocking. However this behaviour is also impacting MongoDB transactions.

The original change WT-6444 was intended to rollback batch operations and have the mongodb layer split them into smaller chunks, as a consequence of this change we are rolling back more than we intended.

There are two possible fixes here:

1. Improve the heuristic used to determine whether we should roll back a transaction.
2. Have MongoDB supply a config to WiredTiger to identify that a MongoDB transaction is running, and skip the rollback logic.

I've created a python reproducer for this scenario:

import time, wiredtiger, wttest

from wtscenario import make_scenarios

def timestamp_str(t):

    return '%x' % t

class test_repro01(wttest.WiredTigerTestCase):

    conn_config = 'cache_size=10000MB,eviction=(threads_max=1)'

    session_config = 'isolation=snapshot'

    def test_repro01(self):

        uri = 'table:test_repro01'

        self.session.create(uri, 'key_format=i,value_format=S')

        self.conn.set_timestamp('oldest_timestamp=' + timestamp_str(1))

        cursor = self.session.open_cursor(uri)

        doc_count = 30000

        value1 = 'x' * 1000

        for j in range(0, 9):

            self.session.begin_transaction()

            for i in range(j*doc_count, (j+1)*doc_count):

                cursor[i] = value1

            self.session.commit_transaction('commit_timestamp=' + timestamp_str(2))