[SERVER-31281] TransactionReaper should use something other than lastWriteOpTimeTs for staleness Created: 27/Sep/17  Updated: 08/Jan/24  Resolved: 26/Oct/17

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 3.5.13
Fix Version/s: 3.6.0-rc2

Type: Bug Priority: Major - P3
Reporter: Randolph Tan Assignee: Kaloian Manassiev
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-31678 Thread through the operation wall-clo... Closed
Related
related to SERVER-32159 fix typo in sync_tail.cpp fillWriterV... Closed
Backwards Compatibility: Minor Change
Operating System: ALL
Sprint: Sharding 2017-10-23, Sharding 2017-11-13
Participants:
Linked BF Score: 0

 Description   

The TransactionReaper mistakenly uses the time component of lastWriteOpTimeTs to notice transaction records over N minutes old (which we use to decide when transaction records are eligible for deletion due to a lack of a session record).

We should flush an additional field to the transaction table which includes a wall clock time to compare against, as well as a redirecting the reaper to use that field for eligibility.



 Comments   
Comment by Githook User [ 26/Oct/17 ]

Author:

{'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev', 'username': 'kaloianm'}

Message: SERVER-31281 Use separate wallclock time to track the last use of a transaction
Branch: master
https://github.com/mongodb/mongo/commit/b5d1d9c4c0cfe0886cc65ef20327c51d79877a27

Comment by Githook User [ 25/Oct/17 ]

Author:

{'email': 'judah@mongodb.com', 'name': 'Judah Schvimer', 'username': 'judahschvimer'}

Message: Revert "SERVER-31281 Use separate wallclock time to track the last use of a transaction"

This reverts commit 0935d7067068b3cb62a802a8696dd39c8d7e1944.
Branch: master
https://github.com/mongodb/mongo/commit/eadebad07fc0e7aa02d0b407f60af9bcf19fde16

Comment by Kaloian Manassiev [ 25/Oct/17 ]

The backwards compatibility impact of this change is that unused sessions created in 3.6.0-RC0/RC1 won't be able to be cleaned up by a 3.6.0-RC2 instance or newer, due to a missing lastWriteDate field.

Comment by Githook User [ 25/Oct/17 ]

Author:

{'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev', 'username': 'kaloianm'}

Message: SERVER-31281 Use separate wallclock time to track the last use of a transaction
Branch: master
https://github.com/mongodb/mongo/commit/0935d7067068b3cb62a802a8696dd39c8d7e1944

Comment by Githook User [ 20/Oct/17 ]

Author:

{'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev', 'username': 'kaloianm'}

Message: SERVER-31281 Combine computeLatestTransactionTableRecords and fillWriterVectorsAndLastestSessionRecords
Branch: master
https://github.com/mongodb/mongo/commit/cb72da029c5ed5605977483524f803775e3b8953

Comment by Mira Carey [ 29/Sep/17 ]

We can, but then we'll need another field that represents the wall clock time of the write

Comment by Kaloian Manassiev [ 28/Sep/17 ]

This is correct, the session cleanup code should not be looking into the config.transactions collection at all. mira.carey@mongodb.com, can we get rid of the part which checks the last write for a session? This value has no good wall clock meaning and cannot be used to gauge recency.

Comment by Andy Schwerin [ 27/Sep/17 ]

Yeah, I think so. But what is the "transaction reaper"? I thought that cleanup was going to be driven by session expiration, handled by some component of the logical sessions system?

Comment by Randolph Tan [ 27/Sep/17 ]

The field the reaper that the query is using is the oplog timestamp, which is directly co-related to the LogicalClock and not the wall clock time. Sounds like we might need a new field to store the wallclock time.

Comment by Andy Schwerin [ 27/Sep/17 ]

Why? The logical clock cannot be safely used to measure the passage of wall time, and wall time is what determines when a transaction is old enough to real.

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