[SERVER-36485] ‘killSessions’ (for one session) and 'endSessions' should return a “PreparedTransactionInProgress” error if it tries to kill a session that has a prepared transaction in it Created: 07/Aug/18  Updated: 29/Oct/23  Resolved: 16/Jan/19

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

Type: Task Priority: Major - P3
Reporter: Judah Schvimer Assignee: Misha Tyulenev
Resolution: Fixed Votes: 0
Labels: prepare_errors
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-37348 TransactionReaper and periodic transa... Closed
Duplicate
is duplicated by SERVER-36486 Return "PreparedTransactionInProgress... Closed
Related
related to SERVER-38190 killOp while committing a prepared tr... Closed
related to SERVER-38297 Killing session on a secondary curren... Closed
related to SERVER-37671 Log when we are unable to kill a sess... Backlog
is related to SERVER-36497 block returning from setFeatureCompat... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2018-08-27, Sharding 2019-01-28
Participants:

 Comments   
Comment by Githook User [ 16/Jan/19 ]

Author:

{'username': 'mikety', 'email': 'misha@mongodb.com', 'name': 'Misha Tyulenev'}

Message: SERVER-36485 killSessions to ignore sessions with prepared transactions
Branch: master
https://github.com/mongodb/mongo/commit/e5e108115f91a193bfd61f324a68d58c88e193a4

Comment by Judah Schvimer [ 02/Jan/19 ]

This SGTM, if kaloian.manassiev agrees that doing nothing is acceptable (though maybe not ideal), then we'll de-prioritize this towards the end of the project. We definitely should at least test that prepared transactions cannot be killed with killSessions as part of this ticket.

Comment by Tess Avitabile (Inactive) [ 17/Dec/18 ]

SGTM. I think we could also do nothing, since abortArbitraryTransaction() does not abort prepared transactions. But if it's helpful to avoid killing the operation context, then we can make that change.

Comment by Kaloian Manassiev [ 17/Dec/18 ]

OK great, in that case for this ticket we should implement the solution in (2) above: add a check here that the transaction is not prepared, so that the operation context of any prepared transactions does not get interrupted accidentally, like we do with the expired transactions.

Comment by Tess Avitabile (Inactive) [ 17/Dec/18 ]

Re (2): I think it is acceptable for killSessions to silently ignore sessions with prepared transactions.

Re (3): We are no longer planning to abort all transactions on FCV downgrade, so that call to killSessionsLocalKillTransactions will be removed. We have work planned to block FCV downgrade until there are no more prepared transactions: SERVER-36497.

Comment by Kaloian Manassiev [ 14/Dec/18 ]

The endSessions command is asynchronous and as such there is no way to return any value from it. Regardless of this though, if there is a prepared transaction on such a session, the session will not be ended regardless until the transaction commits, so this should not be a problem.

For killSession - it uses the SessionsKiller, which kills sessions in batches. Its return value doesn't convey anything about the individual sessions that were attempted to be killed and on top of that it can also aggregate killing sessions from different calls, so it is hard to pass any success or failure information back.

I have a couple of questions:

  1. If we want killSessions on the shards to be able to return some status on the session which was requested to be killed, the interface of the SessionsKiller will have to change. However, given that the same class is used between MongoS and MongoD I am not sure how easy that is to achieve. misha.tyulenev?
  2. Because of (1), I think it would be very difficult to implement this ticket as stated in the description, but if the intention is to just make sure neither of these commands will inadvertently abort a prepared transaction, then we can just add a check here that the transaction is not prepared, like we do with the expired transactions. tess.avitabile?
  3. Since killSessionsLocalKillTransactions is also used on FCV downgrade, we will have to do some work in FCV downgrade to ensure that it drains all the prepared transactions and doesn't allow new ones to start. tess.avitabile, is there some FCV work to drain (or force-kill) prepared transactions on downgrade? As implemented now, they will be force-killed, which is probably not right.
Generated at Thu Feb 08 04:43:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.