The 60-second limit is the default maximum runtime for transactions; exceeding it marks them as expired for cleanup, but the more severe consequence is that uncommitted transactions pin modified data in the WiredTiger cache, preventing eviction and potentially causing system hangs.
MongoDB imposes a default runtime limit of 60 seconds on multi-document transactions . This limit is controlled by the transactionLifetimeLimitSeconds parameter and is enforced by a background process that periodically aborts expired transactions to prevent them from consuming resources indefinitely . While this timeout protects the system from abandoned transactions, a more critical issue occurs when a long-running transaction remains open but within the limit: it can severely impact the WiredTiger storage engine's cache management.
WiredTiger uses a cache to store in-memory data pages. For performance reasons, it cannot evict (write to disk) pages that contain uncommitted changes from an active transaction . As a long-running transaction modifies data, those modified pages become pinned in the cache. If many pages accumulate uncommitted changes, the dirty cache (the portion with unsaved changes) grows. When the dirty cache reaches 20% of the total cache size, WiredTiger triggers aggressive eviction, which consumes application threads and can halt query processing . In extreme cases, if the dirty cache grows too large and eviction cannot proceed due to pinned uncommitted data, the entire system can hang, with operations getting stuck waiting for cache space .
Cache starvation: Transactions holding open for long periods prevent WiredTiger from evicting pages, causing the cache to fill with uncommitted data and starving other operations of memory .
Dirty cache threshold breach: When dirty bytes exceed 20% of cache, MongoDB prioritizes cache eviction over normal operations, drastically reducing throughput . Some versions may even abort transactions when dirty cache reaches just 10% .
System hangs: In severe cases, with uncommitted updates spanning many pages, WiredTiger can become completely stuck, unable to evict anything, leading to a hung database .
Expired transaction cleanup: If a transaction exceeds
transactionLifetimeLimitSeconds, a background process aborts it, but only after the damage to the cache may already be done .
To avoid these issues, always keep transactions short and abort them promptly on errors . The recommended practice is to modify no more than 1000 documents per transaction . If you encounter cache pressure, scale your resources (RAM, disk I/O) rather than increasing cache size or adjusting internal eviction thresholds, which MongoDB strongly discourages . For large operations, consider splitting them into smaller batches and using retry logic to maintain consistency without tying up cache resources .