<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 04:15:25 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[SERVER-27534] All writing operations must fail if the term changes</title>
                <link>https://jira.mongodb.org/browse/SERVER-27534</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;Consider the following sequence of events during an batch insert of 1000 documents with ordered:true and w:majority writeConcern.&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;Insert 500 documents and unlock&lt;/li&gt;
	&lt;li&gt;Pause the inserting thread&lt;/li&gt;
	&lt;li&gt;Another node steps up and the original primary rolls back the 500 writes already done&lt;/li&gt;
	&lt;li&gt;The original primary steps back up&lt;/li&gt;
	&lt;li&gt;The inserting thread then does the remaining writes which get new optimes&lt;/li&gt;
	&lt;li&gt;That thread then waits for majority confirmation of the last writes, and successfully returns to the user&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;In this case we&apos;ve lost 500 writes that are w:majority confirmed, and we&apos;ve written later ops without the earlier ops even with ordered:true. This is caused by a combination of not killing all ops (at least all writing ops) on all replSet stepdown paths, not closing all connections, and always asking &quot;can I currently write to this namespace&quot; rather than &quot;have I always been able to write to this namespace since starting this op&quot;.&lt;/p&gt;

&lt;p&gt;This issue also effects any operations that write multiple oplog entries with a release of the global lock in between, and &quot;no-op&quot; ops that get the last optime after releasing the global lock. A non-exhaustive list:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;All batch write operations (insert, update, delete)&lt;/li&gt;
	&lt;li&gt;Multi-update and Multi-delete&lt;/li&gt;
	&lt;li&gt;Agg with $out&lt;/li&gt;
	&lt;li&gt;MapReduce&lt;/li&gt;
&lt;/ul&gt;



&lt;p&gt;Potential solutions:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;Fail all write ops and waitForWriteConcern if the electionId (or rbid) changed since the op began&lt;/li&gt;
	&lt;li&gt;Interrupt all write ops (or all ops) on all stepdown paths. Also need to either:&lt;br/&gt;
a) Ensure all write ops check for interrupt every time they aquire the global lock &lt;b&gt;after&lt;/b&gt; acquiring it (currently they check first)&lt;br/&gt;
b) Make all lock acquisitions checkForInterrupt (this is planned already to support interruptable locking)&lt;/li&gt;
	&lt;li&gt;Record the term at the beginning of every operation, in the logOp (and awaitReplication) code check that the term of the write matches what was recorded and abort the write if not.&lt;/li&gt;
&lt;/ol&gt;
</description>
                <environment></environment>
        <key id="341404">SERVER-27534</key>
            <summary>All writing operations must fail if the term changes</summary>
                <type id="1" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14703&amp;avatarType=issuetype">Bug</type>
                                            <priority id="2" iconUrl="https://jira.mongodb.org/images/icons/priorities/critical.svg">Critical - P2</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="9">Done</resolution>
                                        <assignee username="justin.seyster@mongodb.com">Justin Seyster</assignee>
                                    <reporter username="mathias@mongodb.com">Mathias Stearn</reporter>
                        <labels>
                    </labels>
                <created>Wed, 28 Dec 2016 18:28:42 +0000</created>
                <updated>Tue, 16 Aug 2022 20:01:41 +0000</updated>
                            <resolved>Thu, 19 Apr 2018 02:55:02 +0000</resolved>
                                                    <fixVersion>3.6.5</fixVersion>
                    <fixVersion>3.7.6</fixVersion>
                                    <component>Replication</component>
                    <component>Write Ops</component>
                                        <votes>0</votes>
                                    <watches>22</watches>
                                                                                                                <comments>
                            <comment id="2186759" author="david.storch" created="Wed, 20 Mar 2019 21:55:08 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=tess.avitabile&quot; class=&quot;user-hover&quot; rel=&quot;tess.avitabile&quot;&gt;tess.avitabile&lt;/a&gt;, I don&apos;t recall if there was a specific reason that we did not backport this to 3.4. It looks like it would theoretically be possible to backport, though I don&apos;t recall all of the details. &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=justin.seyster&quot; class=&quot;user-hover&quot; rel=&quot;justin.seyster&quot;&gt;justin.seyster&lt;/a&gt; might remember more than me.&lt;/p&gt;</comment>
                            <comment id="2184238" author="tess.avitabile" created="Mon, 18 Mar 2019 19:50:27 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=david.storch&quot; class=&quot;user-hover&quot; rel=&quot;david.storch&quot;&gt;david.storch&lt;/a&gt;, &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=justin.seyster&quot; class=&quot;user-hover&quot; rel=&quot;justin.seyster&quot;&gt;justin.seyster&lt;/a&gt;, do you know why we did not backport this to 3.4? Did the issue not exist on 3.4? I am wondering because I am considering how far to backport&#160;&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-37574&quot; title=&quot;Force reconfig should kill user operations&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-37574&quot;&gt;&lt;del&gt;SERVER-37574&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="1886490" author="xgen-internal-githook" created="Tue, 8 May 2018 23:08:59 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;justin.seyster@mongodb.com&apos;, &apos;name&apos;: &apos;Justin Seyster&apos;, &apos;username&apos;: &apos;jseyster&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-27534&quot; title=&quot;All writing operations must fail if the term changes&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-27534&quot;&gt;&lt;del&gt;SERVER-27534&lt;/del&gt;&lt;/a&gt; All writing operations must fail if the term changes&lt;/p&gt;

&lt;p&gt;Note that in our master branch, we committed a more ambitious fix for&lt;br/&gt;
this, which modifies lock acquisitions to always check for interrupt&lt;br/&gt;
(obviating the need for the interrupt checks in these batch modify&lt;br/&gt;
functions). That will hopefully prevent future problems like this.&lt;/p&gt;

&lt;p&gt;On the 3.6 branch, though, we just fix the case described in the Jira&lt;br/&gt;
ticket by moving interrupt checks to happen after we take a collection&lt;br/&gt;
lock (which helps because a stepdown can&apos;t occur while the lock is&lt;br/&gt;
held).&lt;br/&gt;
Branch: v3.6&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/97f6f0e4612fa04f7268c6f354c7065281075267&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/97f6f0e4612fa04f7268c6f354c7065281075267&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1868188" author="xgen-internal-githook" created="Wed, 18 Apr 2018 20:59:49 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;justin.seyster@mongodb.com&apos;, &apos;name&apos;: &apos;Justin Seyster&apos;, &apos;username&apos;: &apos;jseyster&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-27534&quot; title=&quot;All writing operations must fail if the term changes&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-27534&quot;&gt;&lt;del&gt;SERVER-27534&lt;/del&gt;&lt;/a&gt; All writing operations must fail if the term changes.&lt;/p&gt;

&lt;p&gt;This reapplies bc19d43f, which was reverted by ae50776b. It also adds&lt;br/&gt;
more test fixes.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/d9a5a306690d7cdb8831e64441a66cdd503d8064&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/d9a5a306690d7cdb8831e64441a66cdd503d8064&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1864352" author="justin.seyster" created="Sat, 14 Apr 2018 00:52:33 +0000"  >&lt;p&gt;Reverted, because of a failing test. This should be back in the build early next week.&lt;/p&gt;</comment>
                            <comment id="1864351" author="xgen-internal-githook" created="Sat, 14 Apr 2018 00:51:11 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;justin.seyster@mongodb.com&apos;, &apos;name&apos;: &apos;Justin Seyster&apos;, &apos;username&apos;: &apos;jseyster&apos;}
&lt;p&gt;Message: Revert &quot;&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-27534&quot; title=&quot;All writing operations must fail if the term changes&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-27534&quot;&gt;&lt;del&gt;SERVER-27534&lt;/del&gt;&lt;/a&gt; All writing operations must fail if the term changes.&quot;&lt;/p&gt;

&lt;p&gt;This reverts commit bc19d43fdc4aab85264def96f638128c0ddb8483.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/ae50776bce051930d8d68493aa13c71cdcef4970&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/ae50776bce051930d8d68493aa13c71cdcef4970&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1862958" author="xgen-internal-githook" created="Thu, 12 Apr 2018 20:24:44 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;justin.seyster@mongodb.com&apos;, &apos;name&apos;: &apos;Justin Seyster&apos;, &apos;username&apos;: &apos;jseyster&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-27534&quot; title=&quot;All writing operations must fail if the term changes&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-27534&quot;&gt;&lt;del&gt;SERVER-27534&lt;/del&gt;&lt;/a&gt; All writing operations must fail if the term changes.&lt;/p&gt;

&lt;p&gt;The description of this SERVER ticket describes a nasty race that can&lt;br/&gt;
occur if elections happen inbetween two batches during a large&lt;br/&gt;
update. (The included test confirms that the race is possible.)&lt;/p&gt;

&lt;p&gt;To fix this, we want to check the operation context for interrupts&lt;br/&gt;
with each batch, and we need to make sure the check happens &lt;em&gt;after&lt;/em&gt;&lt;br/&gt;
the collection lock gets taken and before the batch&lt;br/&gt;
inserts/updates/deletes execute.&lt;/p&gt;

&lt;p&gt;A recent change to locking gives us almost exactly this for free: if a&lt;br/&gt;
collection lock has to wait, it throws an exception when the operation&lt;br/&gt;
context is interrupted, ending the operation. If the lock doesn&apos;t&lt;br/&gt;
wait, though, there is no check.&lt;/p&gt;

&lt;p&gt;This patch adds that check in. Acquiring a lock now always throws if&lt;br/&gt;
the operation context is interrupted, which closes the race window in&lt;br/&gt;
this bug.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/bc19d43fdc4aab85264def96f638128c0ddb8483&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/bc19d43fdc4aab85264def96f638128c0ddb8483&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1831345" author="justin.seyster" created="Mon, 12 Mar 2018 20:48:55 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=geert.bosch&quot; class=&quot;user-hover&quot; rel=&quot;geert.bosch&quot;&gt;geert.bosch&lt;/a&gt; I was thinking of the new behavior in &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32638&quot; title=&quot;Permit dblock acquisition waiting to be interruptible by killOp&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32638&quot;&gt;&lt;del&gt;SERVER-32638&lt;/del&gt;&lt;/a&gt;: if the current operation context is marked as killed (interrupted), DB lock acquisition calls do not even try to wait for the lock. Instead, they immediately fail (by uasserting).&lt;/p&gt;

&lt;p&gt;It seems reasonable (though certainly not necessary) to expect parallel behavior when acquiring a lock without waiting. I want to check that we&apos;ve all agreed on the semantics of this operation before I start adding new checkForInterrupt calls (solution 2a in the description).&lt;/p&gt;</comment>
                            <comment id="1830016" author="geert.bosch" created="Sun, 11 Mar 2018 14:36:04 +0000"  >&lt;p&gt;Normally the expectation is that any operation does only a bounded amount&lt;br/&gt;
of work before unlocking/relocking. You want to do &lt;em&gt;some&lt;/em&gt; work after&lt;br/&gt;
obtaining locks. We don&apos;t asynchronously stop operations, so there is&lt;br/&gt;
nothing special about the instant we have gotten a lock, or 5 statements&lt;br/&gt;
later. In particular, if you&apos;d get a lock with a timeout of 0, the desired&lt;br/&gt;
behavior is that of a try-lock where you don&apos;t have to wait. If you&apos;d go&lt;br/&gt;
check if no time has passed after obtaining the lock, it would always fail,&lt;br/&gt;
even if the lock was not contended.&lt;/p&gt;

&lt;p&gt;On Fri, Mar 9, 2018 at 6:57 PM, Justin Seyster (JIRA) &amp;lt;jira@mongodb.org&amp;gt;&lt;/p&gt;
</comment>
                            <comment id="1829608" author="justin.seyster" created="Fri, 9 Mar 2018 23:56:13 +0000"  >&lt;p&gt;It looks like &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32638&quot; title=&quot;Permit dblock acquisition waiting to be interruptible by killOp&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32638&quot;&gt;&lt;del&gt;SERVER-32638&lt;/del&gt;&lt;/a&gt; is not enough to prevent this scenario, because acquiring a DBLock in an interrupted op context only uasserts if the DBLock has to wait. An uncontested acquisition will always succeed, so we&apos;ll still need to add checkForInterrupt calls after acquiring the DBLock (solution 2a in the description).&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=louis.williams&quot; class=&quot;user-hover&quot; rel=&quot;louis.williams&quot;&gt;louis.williams&lt;/a&gt; Is that the originally intended behavior for interruptible DBLocks?&lt;/p&gt;</comment>
                            <comment id="1815005" author="geert.bosch" created="Fri, 23 Feb 2018 23:37:17 +0000"  >&lt;p&gt;I&apos;m arguing that &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32638&quot; title=&quot;Permit dblock acquisition waiting to be interruptible by killOp&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32638&quot;&gt;&lt;del&gt;SERVER-32638&lt;/del&gt;&lt;/a&gt; looks unsafe for back-porting. For just mainline I agree approach 2B should be fine.&lt;/p&gt;</comment>
                            <comment id="1812293" author="spencer" created="Wed, 21 Feb 2018 23:09:57 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=geert.bosch&quot; class=&quot;user-hover&quot; rel=&quot;geert.bosch&quot;&gt;geert.bosch&lt;/a&gt;, are you suggesting that we go with the 2A approach from the description, rather than the 2B approach as we had planned?  Or are you suggesting that after &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32638&quot; title=&quot;Permit dblock acquisition waiting to be interruptible by killOp&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32638&quot;&gt;&lt;del&gt;SERVER-32638&lt;/del&gt;&lt;/a&gt; we specifically audit the handful of commands that can do writes and ensure that all of them are opting in to this lock interruptability behavior?&lt;/p&gt;</comment>
                            <comment id="1804993" author="geert.bosch" created="Tue, 13 Feb 2018 22:24:44 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32638&quot; title=&quot;Permit dblock acquisition waiting to be interruptible by killOp&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32638&quot;&gt;&lt;del&gt;SERVER-32638&lt;/del&gt;&lt;/a&gt; currently exposes a lot of places in the code that acquire locks, but are not prepared by such an attempt to throw an exception. While we&apos;re working toward removing all such cases for MongoDB 4.0, it will take a while before we can be confident on having handled all locations. This clearly is not safe for back porting.&lt;/p&gt;

&lt;p&gt;It probably would be better to add explicit checks for interrupts at a few specific places where we can make sure exceptions are handled correctly.&lt;/p&gt;</comment>
                            <comment id="1772809" author="schwerin" created="Fri, 12 Jan 2018 15:53:18 +0000"  >&lt;p&gt;On master, this ticket can be resolved after &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32638&quot; title=&quot;Permit dblock acquisition waiting to be interruptible by killOp&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32638&quot;&gt;&lt;del&gt;SERVER-32638&lt;/del&gt;&lt;/a&gt; commits.&lt;/p&gt;</comment>
                            <comment id="1772801" author="milkie" created="Fri, 12 Jan 2018 15:49:27 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32638&quot; title=&quot;Permit dblock acquisition waiting to be interruptible by killOp&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32638&quot;&gt;&lt;del&gt;SERVER-32638&lt;/del&gt;&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1772795" author="schwerin" created="Fri, 12 Jan 2018 15:46:06 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=milkie&quot; class=&quot;user-hover&quot; rel=&quot;milkie&quot;&gt;milkie&lt;/a&gt;, is 2b in the proposed solution on the docket for 3.8?&lt;/p&gt;</comment>
                            <comment id="1757894" author="spencer" created="Thu, 21 Dec 2017 16:20:14 +0000"  >&lt;p&gt;We&apos;ll need to check batch command locking for times we drop the lock outside of query yield system.  Any write operation that drops locks will need to checkForInterrupt after re-acquiring their locks.&lt;/p&gt;</comment>
                            <comment id="1712423" author="david.storch" created="Mon, 30 Oct 2017 14:35:48 +0000"  >&lt;p&gt;If I understand correctly, 2a should be fairly straightforward. This work is not planned to be accomplished outside of a fix for this ticket.&lt;/p&gt;</comment>
                            <comment id="1711703" author="milkie" created="Fri, 27 Oct 2017 21:06:46 +0000"  >&lt;p&gt;I don&apos;t believe 2b is planned soon, but I can&apos;t really tell because I was actually unable to find a ticket reflecting this work on the storage backlog.  Is anyone aware of one?&lt;/p&gt;</comment>
                            <comment id="1711574" author="spencer" created="Fri, 27 Oct 2017 19:44:49 +0000"  >&lt;p&gt;2a seems like it belongs on the query team, while 2b seems like it belongs to storage.  &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=david.storch&quot; class=&quot;user-hover&quot; rel=&quot;david.storch&quot;&gt;david.storch&lt;/a&gt; &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=milkie&quot; class=&quot;user-hover&quot; rel=&quot;milkie&quot;&gt;milkie&lt;/a&gt;, can you comment on the relative complexity of 2a and 2b and whether either is currently planned anytime soon?&lt;/p&gt;</comment>
                            <comment id="1711572" author="spencer" created="Fri, 27 Oct 2017 19:42:05 +0000"  >&lt;p&gt;The first part of solution #2 has been implemented.  Now we just need to do either 2a or 2b to be safe from this issue.&lt;/p&gt;</comment>
                            <comment id="1682659" author="spencer" created="Tue, 26 Sep 2017 22:40:28 +0000"  >&lt;p&gt;This problem may disappear when &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-31277&quot; title=&quot;Cancel all user operations on heartbeat stepdown path&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-31277&quot;&gt;&lt;del&gt;SERVER-31277&lt;/del&gt;&lt;/a&gt; is implemented&lt;/p&gt;</comment>
                            <comment id="1667545" author="redbeard0531" created="Thu, 7 Sep 2017 22:26:37 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=spencer&quot; class=&quot;user-hover&quot; rel=&quot;spencer&quot;&gt;spencer&lt;/a&gt; &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=matthew.russotto&quot; class=&quot;user-hover&quot; rel=&quot;matthew.russotto&quot;&gt;matthew.russotto&lt;/a&gt; &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=renctan&quot; class=&quot;user-hover&quot; rel=&quot;renctan&quot;&gt;renctan&lt;/a&gt; We just discussed another interesting case that a fix for this should handle. If a single operation does a read followed by a write, we must ensure that there was no rollback between them. It is probably best in general to check for rollback every time the global lock is acquired rather than trying to find a smaller subset of cases.&lt;/p&gt;</comment>
                            <comment id="1550876" author="spencer" created="Mon, 17 Apr 2017 20:15:53 +0000"  >&lt;p&gt;Note the naive implementation will add an extra mutex acquisition to every command execution.  If we want to avoid that we may be able to add a cached copy of the current term to ReplicationCoordinator that has the same concurrency rules as _canAcceptNonLocalWrites, and decorate the opctx with the term at the same place as the command execution code calls canAcceptWritesFor to check that the command is safe to run.&lt;/p&gt;</comment>
                            <comment id="1550861" author="spencer" created="Mon, 17 Apr 2017 20:03:52 +0000"  >&lt;p&gt;Probably the best solution is to start decorating the operation context at the beginning of command execution with the current term, then checking in logOp and awaitReplication that the term of the optime being written or waited for hasn&apos;t changed from the term that was recorded on the opctx.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10420">
                    <name>Backports</name>
                                            <outwardlinks description="backported by">
                                                        </outwardlinks>
                                                        </issuelinktype>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                                                <inwardlinks description="is depended on by">
                                                        </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10520">
                    <name>Problem/Incident</name>
                                            <outwardlinks description="causes">
                                        <issuelink>
            <issuekey id="534357">SERVER-34682</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="534012">SERVER-34672</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="617120">SERVER-37574</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="2115454">SERVER-68874</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="611497">SERVER-37381</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="641410">SERVER-38354</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="433308">SERVER-31277</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="341660">SERVER-27545</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                <customfield id="customfield_10050" key="com.atlassian.jira.toolkit:comments">
                        <customfieldname># Replies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>25.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18555" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname># of Sprints</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9.0</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_12450" key="com.atlassian.jira.plugin.system.customfieldtypes:multicheckboxes">
                        <customfieldname>Backport Requested</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="15141"><![CDATA[v3.6]]></customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10011" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Backwards Compatibility</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10038"><![CDATA[Fully Compatible]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Tue, 3 Jan 2017 15:08:56 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        4 years, 47 weeks ago
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18254" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Dependencies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[]]></customfieldvalue>


                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                    <customfield id="customfield_14262" key="com.atlassian.jira.plugin.system.customfieldtypes:datepicker">
                        <customfieldname>End date</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Tue, 26 Sep 2017 23:59:59 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10057" key="com.atlassian.jira.toolkit:lastusercommented">
                        <customfieldname>Last comment by Customer</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>true</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10056" key="com.atlassian.jira.toolkit:lastupdaterorcommenter">
                        <customfieldname>Last commenter</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>dianna.hohensee@mongodb.com</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11151" key="com.atlassian.jira.toolkit:LastCommentDate">
                        <customfieldname>Last public comment date</customfieldname>
                        <customfieldvalues>
                            4 years, 47 weeks ago
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_16465" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Linked BF Score</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>68.0</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10032" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Operating System</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10026"><![CDATA[ALL]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>schwerin@mongodb.com</customfieldvalue>
            <customfieldvalue>david.storch@mongodb.com</customfieldvalue>
            <customfieldvalue>milkie@mongodb.com</customfieldvalue>
            <customfieldvalue>geert.bosch@mongodb.com</customfieldvalue>
            <customfieldvalue>xgen-internal-githook</customfieldvalue>
            <customfieldvalue>justin.seyster@mongodb.com</customfieldvalue>
            <customfieldvalue>mathias@mongodb.com</customfieldvalue>
            <customfieldvalue>spencer@mongodb.com</customfieldvalue>
            <customfieldvalue>tess.avitabile@mongodb.com</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|ht093j:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hr8y53:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9223372036854775807</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_23361" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Requested By</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_10557" key="com.pyxis.greenhopper.jira:gh-sprint">
                        <customfieldname>Sprint</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue id="1893">Repl 2017-10-02</customfieldvalue>
    <customfieldvalue id="1915">Repl 2017-10-23</customfieldvalue>
    <customfieldvalue id="1931">Repl 2017-11-13</customfieldvalue>
    <customfieldvalue id="1957">Repl 2017-12-04</customfieldvalue>
    <customfieldvalue id="2031">Repl 2017-12-18</customfieldvalue>
    <customfieldvalue id="2121">Query 2018-03-12</customfieldvalue>
    <customfieldvalue id="2122">Query 2018-03-26</customfieldvalue>
    <customfieldvalue id="2128">Query 2018-04-09</customfieldvalue>
    <customfieldvalue id="2247">Query 2018-04-23</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_14261" key="com.atlassian.jira.plugin.system.customfieldtypes:datepicker">
                        <customfieldname>Start date</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Wed, 28 Dec 2016 00:00:00 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                <customfield id="customfield_10053" key="com.atlassian.jira.ext.charting:timeinstatus">
                        <customfieldname>Time In Status</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_22870" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Triagers</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_14350" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>serverRank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hs4kgv:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                    </customfields>
    </item>
</channel>
</rss>