# Prepared-transaction conflicts by read concern and write access > Source-anchored research for Prepared-transaction conflicts by read concern and write access. Run status: COMPLETED. Parent: [Distributed Sharded Transactions](https://llms-explorer.com/tree/distributed-sharded-transactions/) · 4 facets · 9 facts · page: https://llms-explorer.com/tree/prepared-transaction-conflicts-by-read-concern-and-write-access/ ## Structure and components - At the WiredTiger 11.0.0 API layer, ignore_prepare=true reads as though the prepared transaction did not exist and forces the reader's transaction to be read-only. ignore_prepare=force also permits updates, but the documentation warns that these updates can cause inconsistency or overwrite a prepared update. This internal API setting is not a MongoDB client read-concern option. (medium confidence) — [source](https://source.wiredtiger.com/11.0.0/timestamp_prepare.html) ## How it works - In MongoDB r8.0.0, canIgnorePrepareConflicts returns false whenever the operation is in a multi-document transaction, before checking the read-concern level. Thus the outside-transaction shortcut for local or majority must not be applied to transactional reads; these reads enforce prepare conflicts when encountered. (low confidence) — [source](https://github.com/mongodb/mongo/blob/r8.0.0/src/mongo/db/read_concern_mongod.cpp) - MongoDB r8.0.0 handles WT_PREPARE_CONFLICT by retrying the storage operation, incrementing prepare-read-conflict metrics, and waiting for a prepared unit of work to commit or abort when the conflict persists. The historical WT-4366 discussion distinguishes this no-answer-yet read condition from WT_ROLLBACK, which normally requires transaction rollback. (medium confidence) — [source](https://github.com/mongodb/mongo/blob/r8.0.0/src/mongo/db/storage/wiredtiger/wiredtiger_prepare_conflict.cpp) - MongoDB r8.0.0's wiredTigerPrepareConflictRetrySlow normally retries WT_PREPARE_CONFLICT and waits for a prepared unit of work to commit or abort. If the operation's recovery unit is already timestamped and holds an oplog slot, the function instead throws a write-conflict exception to abort and retry, because blocking could prevent replication needed to resolve the prepared update. (low confidence) — [source](https://github.com/mongodb/mongo/blob/r8.0.0/src/mongo/db/storage/wiredtiger/wiredtiger_prepare_conflict.cpp) - Prepared conflicts can arise through unique-index access even when the incoming document has another _id. SERVER-40380 specifies a test that inserts {_id:1,a:1} in a transaction, unsets a, prepares, then inserts {_id:2,a:1} outside the transaction; that insert must encounter a prepare conflict. This is a historical test specification, not evidence of a current incident. (low confidence) — [source](https://jira.mongodb.org/browse/SERVER-40380) ## Problems, failure modes and limitations - A write targeting a document modified by an unresolved prepared transaction waits before proceeding. The Nanjing University/Tencent model, evaluated on MongoDB 4.4.5, describes delaying an update through a read of the same key; Huawei DDS source analysis independently describes waiting for prepared-state resolution. Resolution permits retry, not guaranteed write success: a subsequent write-conflict check can still fail. (medium confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/README.md) ## Facts and statements - For eligible reads outside multi-document transactions in MongoDB r8.0.0, local, available, and majority read concerns can ignore prepared updates and return the earlier data state. canIgnorePrepareConflicts requires one of those three concerns and rejects both afterClusterTime and atClusterTime; the command's requested conflict policy must also permit ignoring conflicts. (medium confidence) — [source](https://raw.githubusercontent.com/mongodb/mongo/b41cda4fe697dce6fd9b83b3805362ccc02fbeb3/src/mongo/db/repl/README.md) - Snapshot, linearizable, and afterClusterTime reads do not receive that bypass. On encountering a relevant prepared update they wait for commit or abort. For timestamped reads, MongoDB explains the blocking condition as read timestamp greater than or equal to the prepare timestamp; the mere existence of a prepared transaction does not imply every snapshot read must wait. (medium confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/README.md) - WiredTiger 11.0.0 documents that ignoring prepared updates does not provide repeatable reads: repeating a read after the prepared transaction resolves can produce a different value. Returning a pre-prepare value must therefore not be treated as proof of snapshot isolation. (low confidence) — [source](https://source.wiredtiger.com/11.0.0/timestamp_prepare.html)