[SERVER-39792] Update the txn table for the first operation in a transaction on primary Created: 25/Feb/19  Updated: 29/Oct/23  Resolved: 25/Mar/19

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

Type: Task Priority: Major - P3
Reporter: Gregory McKeon (Inactive) Assignee: Jason Chan
Resolution: Fixed Votes: 0
Labels: bigtxns_recovery
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-39680 Maintain the oldest active transactio... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2019-03-11, Repl 2019-03-25, Repl 2019-04-08
Participants:

 Description   

We should set the state of the transaction in the transaction table to “in-progress” when we receive the first operation in a transaction on primary.



 Comments   
Comment by Githook User [ 25/Mar/19 ]

Author:

{'email': 'jason.chan@10gen.com', 'name': 'Jason Chan', 'username': 'jasonjhchan'}

Message: SERVER-39792 Update the txn table only on the first txn operation on primary
Branch: master
https://github.com/mongodb/mongo/commit/f8bf360e86ff96a0636575af7d1cee8ae9f0c3f0

Comment by Jason Chan [ 19/Mar/19 ]

judah.schvimer yes, I mean't to say the 'o' field of the prepareTransaction oplog entry specifically. Although, with siyuan.zhou's comment, it seems that it may make more sense to use $set to update the txn table rather than adding an extra field to the prepareTransaction oplog entry.

Comment by Judah Schvimer [ 19/Mar/19 ]

Add a startTimestamp field in the prepareTransaction command

jason.chan, do you mean the prepareTransaction oplog entry?

Comment by Tess Avitabile (Inactive) [ 18/Mar/19 ]

A $set of a single field should not be noticeably slower than document replacement for small documents. The update system code might be slightly slower, since we need to scan the document to find the field to modify, but the WT implementation can be more efficient, since the WT update chain can just store the modified field instead of the whole document. Since the config.transactions document is small, the performance should be about the same.

Comment by Siyuan Zhou [ 18/Mar/19 ]

Great summary! I initially preferred option 1 since it's more explicit and has a smaller scope, but when considering future possible format change, like ops packing, we'd have to include the startTimestamp in the applyOps with prepare field or make it use partial updates eventually. Thus, if $set isn't noticeably slower than document replacement, perhaps it make more sense not to require prepareTransaction or the packed applyOps format know the startTimestamp. CC tess.avitabile for the performance of $set.

Comment by Jason Chan [ 18/Mar/19 ]

siyuan.zhou
Like we discussed, since this ticket includes setting the startTimestamp in the txn table while processing first operation in a transaction on primary, it would be best to also think about how the startTimestamp should be propagated to secondaries. There are two options that seemed like they may make sense:
1. Add a startTimestamp field in the prepareTransaction command. This way seems the most straightforward way. The secondaries will know the startTimestamp information when applying the prepare oplog entry.

2. On secondary application, set the startTimestamp to be the timestamp of the first transaction operation (the prevOpTime will be set to null here) when we encounter it. This may require us to change from updating the entire txn table entry at a time to only doing partial updates so we don't overwrite the startTimestamp when processing the sequence of derived ops to the txn table.

Since there already exists a precedent of including timestamps in transaction commands (commitTimestamp in commit for prepared transactions), I was wondering if there are any strong objections to option 1?

Thoughts? judah.schvimertess.avitabile

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