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))