[SERVER-60879] A update to a prepared document may faild Created: 21/Oct/21  Updated: 10/Jun/22  Resolved: 29/Nov/21

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

Type: Bug Priority: Major - P3
Reporter: Ouyang Tsuna Assignee: Edwin Zhou
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-60880 A update to a prepared document may f... Closed
duplicates SERVER-60881 A update to a prepared document may f... Closed
Operating System: ALL
Participants:

 Description   

As mentioned in the docuemnt, a write to a prepared document should block

 

MongoDB's wiki about Prepare Conflicts

If a write attempts to modify a document that was also modified by a prepared transaction, it will block and wait for the transaction to be committed or aborted before proceeding.

Assume there is a transaction txn2 want to update doc1, and doc1 is prepared by another transaction txn1.

According to this source code, txn1 only waits for a read operation.

WiredTigerRecordStore::updateRecord

 

 

    int ret = wiredTigerPrepareConflictRetry(opCtx, [&] { return c->search(c); });

When txn1 commits or aborts,  txn2 make progress for updating.

According to the code in wiredtiger, a update operation to a prepared upd causes transaction rollback.

There will be a situation as follows:

Concurrent transaction txn3 may update also prepare the document. If txn3 prepared doc1 before txn2 update doc1, txn2's update will failed, which contradicts the content in the document.

The events could be like this:

 

Example

txn1 prepared doc1;

txn2 wants to update doc1 and blocks;

txn1 aborts;

txn2 ends blocking;

txn3 updates doc1 and prepared;

txn2 updates doc1 and failed.

 

txn2 will update after txn1 aborting, otherwise txn1 will rollback dute to txn2's update, so I guess when updating RecordStore, wirte lock are acquired, otherwise something bad will happen.

 



 Comments   
Comment by Edwin Zhou [ 29/Nov/21 ]

Hi tsunaouyang@gmail.com,

We haven’t heard back from you for some time, so I’m going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket.

Best,
Edwin

Comment by Edwin Zhou [ 18/Nov/21 ]

Hi tsunaouyang@gmail.com,

We still need additional information to diagnose the problem. If this is still an issue for you, would you please let us know if you are able to:

  • direct us to a particular incident that has exhibited this behavior?
  • to demonstrate this behavior through a reproduction script?

Best,
Edwin

Comment by Edwin Zhou [ 04/Nov/21 ]

Hi tsunaouyang@gmail.com,

Thanks for your report. To help us investigate this behavior, can you direct us to a particular incident that has exhibited this behavior? Are you able to demonstrate this behavior through a reproduction script? Any guidance toward narrowing down this potential bug will be highly appreciated!

Best,
Edwin

Comment by Ouyang Tsuna [ 21/Oct/21 ]

I am so sorry for opening three same issues due to network problem. It seems like I do not have the privilege to delete issues. Administrators could delete duplicated issues.

Generated at Thu Feb 08 05:50:59 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.