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:
- Improve the heuristic used to determine whether we should roll back a transaction.
- 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))
- is related to
-
SERVER-53464 Transaction with many documents working on MongoDB 4.2 but not 4.4
- Closed
-
WT-6444 Abort a transaction if it is force evicting and oldest
- Closed