TemporarilyUnavailable and TransactionTooLargeForCache errors
Parent: WiredTiger cache eviction and dirty ratio · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for TemporarilyUnavailable and TransactionTooLargeForCache errors. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Measurements and reference values
- A single insert that generates many index entries can create enough dirty transaction state to enter repeated eviction rollbacks. SERVER-61909 reproduces this with a text index and a 256 MB cache; the problem is not restricted to explicit multi-document transactions. (high confidence) [source]
- transactionTooLargeForCacheThreshold defaults to 0.75 of dirty cache. With the documented 20% dirty-cache budget, the illustrative retry boundary is 15% of total cache. It applies after a cache-pressure rollback, not as an unconditional transaction-size cap. (high confidence) (verified as of 2026-10-14) [source]
Problems, failure modes and limitations
- TemporarilyUnavailable can signal repeated storage-engine rollbacks under cache pressure. The failed operation may have caused the pressure or merely suffered from it; the error does not identify which. (high confidence) [source]
- Outside multi-document transactions, MongoDB bounds internal TemporarilyUnavailable retries with temporarilyUnavailableMaxRetries and increases delay using temporarilyUnavailableBackoffBaseMs. Exhausted retries expose the error to the client. (high confidence) [source]
- With the parameter reference's documented 20% dirty-cache limit, multiplying by the 0.75 retry threshold gives 15% of total cache. That conditional calculation does not mean transactions always fail upon occupying 15% of cache. (high confidence) [source]
- SERVER-84007 describes a heuristic blind spot: rollback at the update-bytes limit may miss the dirty-pages test and yield WriteConflict or TemporarilyUnavailable, allowing futile retries. The issue was unresolved in its June 12, 2026 update. (low confidence) (verified as of 2026-06-12) [source]
- temporarilyUnavailableErrors appears in slow-query logging and FTDC, providing evidence of internally encountered cache-pressure errors even when retries eventually succeed. (high confidence) [source]
- MongoDB assigns error code 365 to TemporarilyUnavailable and 388 to TransactionTooLargeForCache. (low confidence) (verified as of 2026-10-30) [source]
Comparisons and alternatives
- In the ordinary write-conflict retry path, operations inside multi-document transactions return WriteConflict rather than exposing TemporarilyUnavailable; this describes that handler, not every possible transaction-abort mechanism. (high confidence) [source]
- The parameter reference lists temporarilyUnavailableMaxRetries with default 10; the storage guide describes bounded retries rather than the indefinite WriteConflict retry loop. (high confidence) (verified as of 2026-10-14) [source]
- For cache-error diagnosis, correlate the temporarilyUnavailableErrors counter in slow logs and FTDC with cache usage, dirty pages and eviction activity. Percona PMM exposes these cache metrics; this correlation is diagnostic context rather than proof of the failing transaction's size. (medium confidence) [source]
Facts and statements
- TransactionTooLargeForCache identifies a cache-pressure rollback that a heuristic judges unlikely to succeed even without concurrent operations; repeating the unchanged transaction is therefore unlikely to help. (high confidence) [source]
- The documented default transactionTooLargeForCacheThreshold is 0.75 of dirty cache, evaluated after a cache-pressure rollback. This is a retry heuristic, not an unconditional hard cap on transaction size; setting it to 1.0 disables the check. (high confidence) (verified as of 2026-10-14) [source]
- The application guide documents TransactionTooLargeForCache as new in MongoDB 6.2 and says the server does not retry it. The storage README instead says prior to 6.3; use release-specific evidence before asserting the exact first version. (medium confidence) (verified as of 2026-10-14) [source]
- Setting transactionTooLargeForCacheThreshold to 1.0 disables this heuristic; it does not create more cache capacity or guarantee that an oversized transaction will complete. (high confidence) [source]
- Uncommitted changes consume WiredTiger cache. Abort abandoned or errored transactions promptly; splitting oversized work into smaller transactions can reduce cache pressure, provided the application accepts the smaller atomic units. (medium confidence) [source]
Children
- No children recorded.