[SERVER-40462]  Disallow transactions on shard servers with writeConcernMajorityJournalDefault = false Created: 03/Apr/19  Updated: 29/Oct/23  Resolved: 29/Apr/19

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

Type: Task Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Lingzhi Deng
Resolution: Fixed Votes: 0
Labels: prepare_errors
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
is documented by DOCS-12662 Docs for SERVER-40462: Disallow tran... Closed
Related
is related to SERVER-38165 Test that prepared transactions work ... Closed
Backwards Compatibility: Minor Change
Sprint: Repl 2019-05-06
Participants:

 Description   

Nodes running with the in-memory storage engine do not support transaction prepare and because of this, currently they cannot participate in cross-shard transactions.

On the chance that we start supporting that and in order to ensure that in-memory nodes and nodes running with writeConcernMajorityJournalDefault = false don't count towards the majority quorum for any w:majority writes done by the coordinator and participant, such writes should be done with j:true.



 Comments   
Comment by Githook User [ 29/Apr/19 ]

Author:

{'name': 'Lingzhi Deng', 'username': 'ldennis', 'email': 'lingzhi.deng@mongodb.com'}

Message: SERVER-40462: Disallow transactions on shard servers with writeConcernMajorityJournalDefault = false
Branch: master
https://github.com/mongodb/mongo/commit/e4b08de746ef4e472bfdd4790fdb2b89d5a62f1a

Comment by Judah Schvimer [ 22/Apr/19 ]

One roadblock this will have to work around is that most of our in-memory tests use fully in-memory sets. We implicitly convert writeConcernMajorityJournalDefault here. We'll have to add a testing exemption in this case. That should be fine since our in-memory tests do not shutdown nodes.

Comment by Alyson Cabral (Inactive) [ 05/Apr/19 ]

(2) disallowing transactions on shard servers that have j:false defaults seems like a good approach.

Comment by Judah Schvimer [ 05/Apr/19 ]

We no longer want to just send j:true. schwerin pointed out that if a user sets writeConcernMajorityJournalDefault = false, we shouldn't just disregard it unilaterally. As a result there are two options, in general:

  1. Allow transactions with writeConcernMajorityJournalDefault = false and have undefined untested coordinator behavior when majority writes get rolled back as a result of the flag being set.
  2. Fail the first command in a transaction if the replica set is configured with writeConcernMajorityJournalDefault = false (and as a result prohibit transactions with writeConcernMajorityJournalDefault = false).

This second option does on its face change behavior from 4.0 which supported writeConcernMajorityJournalDefault = false with transactions. If we wanted to continue that, we could only prohibit transactions on shard-servers with writeConcernMajorityJournalDefault = false to let replica sets that are not part of a sharded cluster support transactions.

We could also allow any single-replica set transaction succeed with writeConcernMajorityJournalDefault = false but fail at prepare time, but I think this is undesirable behavior since it is arbitrary based on where chunks are placed.

alyson.cabral, which behavior would you like?

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