[SERVER-39577] WT RecoveryUnit can see effects of prepared transactions before commit Created: 13/Feb/19  Updated: 06/Dec/22  Resolved: 14/Feb/19

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Pavithra Vetriselvan Assignee: Backlog - Storage Execution Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Storage Execution
Operating System: ALL
Steps To Reproduce:

(function() {
    "use strict";
    load("jstests/core/txns/libs/prepare_helpers.js");    
 
    const dbName = "test";
    const collName = "fast_count_sees_prepare_changes_before_commit";
    const testDB = db.getSiblingDB(dbName);
    const testColl = testDB.getCollection(collName);
    
    testColl.drop({writeConcern: {w: "majority"}});
    assert.commandWorked(testDB.runCommand({create: collName, writeConcern: {w: "majority"}}));
 
    const session = db.getMongo().startSession({causalConsistency: false});
    const sessionDB = session.getDatabase(dbName);
    const sessionColl = sessionDB.getCollection(collName);    
    const doc = {x: 1};    
 
    session.startTransaction();
    assert.commandWorked(sessionColl.insert(doc));
    PrepareHelpers.prepareTransaction(session);    
    assert.eq(testColl.find().itcount(), 0, () => tojson(testColl.find().toArray()));
    assert.eq(testColl.count(), 1, () => tojson(testColl.stats()));    session.abortTransaction_forTesting();
    assert.eq(testColl.find().itcount(), 0, () => tojson(testColl.find().toArray()));
    assert.eq(testColl.count(), 0, () => tojson(testColl.stats()));
}());

Participants:

 Description   

If we prepare a transaction and then call itcount() and count() on the collection outside of the associated session, we see two conflicting values. itcount() will not see the effects of a transaction in prepare, but count() will. 

We should confirm whether or not we expect this behavior.



 Comments   
Comment by Geert Bosch [ 14/Feb/19 ]

This is the behavior we currently have for non-prepared transactions as well. Fast count is not versioned, so you can see updates to counts in uncommitted transactions. They will be rolled back if the transaction is. Same for prepared transactions. While I agree that it would be good to have correctly versioned fast count with proper isolation, that is not in scope right now. So, closing this as won't fix.

Comment by Judah Schvimer [ 14/Feb/19 ]

If we would reverse this behavior we wouldn't see our own writes.

geert.bosch, can you please clarify what you mean by this? Would you like to keep this behavior of external readers counting prepared inserts?

Comment by Geert Bosch [ 14/Feb/19 ]

We can confirm this behavior is expected. This behavior happens today, but is hard to catch, as the delay between incrementing the count and committing the transaction is short. If we would reverse this behavior we wouldn't see our own writes.

Generated at Thu Feb 08 04:52:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.