[SERVER-38906] Multi-document transactions should not perform timestamped read ahead of all-committed Created: 09/Jan/19  Updated: 29/Oct/23  Resolved: 22/Feb/19

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

Type: Task Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: A. Jesse Jiryu Davis
Resolution: Fixed Votes: 0
Labels: prepare_basic
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-38499 Preparing transaction fails and trigg... Closed
Gantt Dependency
has to be done before SERVER-40145 Re-enable test suites that exercise o... Closed
Related
related to SERVER-40352 Transactions that perform untimestamp... Closed
related to SERVER-39364 Audit uses of setLastOpToSystemLastOp... Closed
related to SERVER-69478 remove unnecessary copy in Transactio... Closed
is related to SERVER-34837 Make the default readConcern level fo... Backlog
Backwards Compatibility: Fully Compatible
Sprint: Repl 2019-01-28, Repl 2019-02-11, Repl 2019-02-25, Repl 2019-03-11
Participants:
Linked BF Score: 10

 Description   

Multi-document transactions with read concern level local or majority perform a timestamped read at the lastApplied. Since the lastApplied is ahead of the all-committed, after the work to allow WT read at a timestamp without a snapshot, this could cause these transactions to read uncommitted storage transactions. It is essential that multi-document transactions with read concern level local read at lastApplied, so that w:1 writes are visible to these transactions. As a solution, multi-document transactions reading ahead of all-committed will not perform a timestamped read.



 Comments   
Comment by Githook User [ 22/Feb/19 ]

Author:

{'name': 'A. Jesse Jiryu Davis', 'username': 'ajdavis', 'email': 'jesse@mongodb.com'}

Message: SERVER-38906 Style in noop_write_after_read_only_txn.js
Branch: master
https://github.com/mongodb/mongo/commit/ec803dcdad1cf142af22ae780ac8be5d90f30d15

Comment by Githook User [ 22/Feb/19 ]

Author:

{'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com', 'username': 'ajdavis'}

Message: SERVER-38906 Test readonly txns do noop write
Branch: master
https://github.com/mongodb/mongo/commit/0859dc10b4a43847ee1830de8b80216060a76874

Comment by A. Jesse Jiryu Davis [ 20/Feb/19 ]

Still to do: test that proves local transactions that only read do a noop write.

Comment by Githook User [ 20/Feb/19 ]

Author:

{'name': 'A. Jesse Jiryu Davis', 'username': 'ajdavis', 'email': 'jesse@mongodb.com'}

Message: SERVER-38906 No-op write after readonly transaction
Branch: master
https://github.com/mongodb/mongo/commit/7243f97b4a63dcc0895fb5a5b973bdb1f3cf8bfc

Comment by Githook User [ 20/Feb/19 ]

Author:

{'name': 'A. Jesse Jiryu Davis', 'username': 'ajdavis', 'email': 'jesse@mongodb.com'}

Message: SERVER-38906 Txns read without timestamp by default
Branch: master
https://github.com/mongodb/mongo/commit/951a9eaba9bf9069866aa04e9a450d25cff74d1a

Comment by Tess Avitabile (Inactive) [ 08/Feb/19 ]

jesse, for performing a noop write, you could generalize the utility here.

Comment by Daniel Gottlieb (Inactive) [ 06/Feb/19 ]

There's been some miscommunication (that starts with me). There is a project that can change what readers in front of holes can see, but the outcome may be something other than "possibly read uncommitted data".

Comment by Githook User [ 05/Feb/19 ]

Author:

{'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com', 'username': 'ajdavis'}

Message: SERVER-38906 Test readConcern local txn isolation
Branch: master
https://github.com/mongodb/mongo/commit/c642a5cf025691886bdfd193430bff83171eea2c

Comment by Tess Avitabile (Inactive) [ 04/Feb/19 ]

SERVER-39364 does not indicate a bug in the behavior today. Today we perform a timestamped read for local transactions and wait for the timestamp to be majority committed.

However, I hear your point that transactions that only read should behave like updates where nupdated is 0.

Comment by Andy Schwerin [ 04/Feb/19 ]

Transactions that only read should behave like updates where nupdated is 0. If I understand correctly, SERVER-39364 indicates a bug in that behavior today, but we should move towards having the two behave the same and correctly over time. I'll leave it to tess.avitabile to either correct my logical error or choose the near term strategy to help you make forward progress, depending on if I've understood this ticket correctly.

Comment by A. Jesse Jiryu Davis [ 04/Feb/19 ]

schwerin the solution to this ticket will cause a subtle behavior change that Tess explained to me, I want to check with you that the change is ok.

Consider a multi-statement transaction that only reads, configured with readConcern local and writeConcern majority. (The readConcern is passed with the first command of the transaction, the writeConcern is passed with the commitTransaction command.)

Today, such a transaction reads from the lastApplied timestamp, and then commitTransaction waits for that timestamp to become majority committed. So, I think today's read-only transaction behavior is "speculative majority".

We're changing the code to read with no timestamp. WiredTiger will somehow pick a snapshot for us. When we receive commitTransaction with writeConcern majority, we won't wait for any timestamp to be majority-committed. (We can't get the lastApplied at the end of the transaction and wait for it to be majority-committed, due to SERVER-39364.) So in fact, the writeConcern will just be ignored for read-only transactions with readConcern local.

So, this is a subtle change. Read-only transactions with readConcern local and writeConcern majority will become "truly local", and they'll happily commit without knowing whether they have read data that wasn't majority-committed. This may go against your goal to make “speculative majority” the default readConcern for operations that can write. Is this an okay change or shall we reconsider how to solve this ticket?

Comment by Judah Schvimer [ 31/Jan/19 ]

This ticket should unblacklist tests blacklisted in this commit (SERVER-38783). Any TODOs for SERVER-38499, should also be revisited here.

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