[SERVER-33327] Session::onMigrateCompletedOnPrimary should not update the lastWriteDate field Created: 14/Feb/18 Updated: 29/Oct/23 Resolved: 31/May/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.6, 4.0.0-rc2, 4.1.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Blake Oler |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Backport Requested: |
v4.0, v3.6
|
||||||||||||
| Sprint: | Sharding 2018-05-21, Sharding 2018-06-04 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
It currently overwrites the latest transaction's lastWriteDate with that from the oplog being migrated and thus it can move the lastWriteDate back. This could cause sessions to be cleaned earlier than the actual last time they were written to. Instead, it should just keep the value as is since migrations don't really modify the state of the config.transactions from the point of view of a sharded cluster. |
| Comments |
| Comment by Githook User [ 19/Jun/18 ] |
|
Author: {'username': 'BlakeIsBlake', 'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com'}Message: (cherry picked from commit 52b37851285c2b5394f0a89edd0c117a8144812c) |
| Comment by Githook User [ 31/May/18 ] |
|
Author: {'username': 'BlakeIsBlake', 'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com'}Message: (cherry picked from commit 52b37851285c2b5394f0a89edd0c117a8144812c) |
| Comment by Githook User [ 29/May/18 ] |
|
Author: {'username': 'BlakeIsBlake', 'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com'}Message: |
| Comment by Kaloian Manassiev [ 15/Feb/18 ] |
|
The lastWriteDate will only be overwritten if the migration is moving the same txnNumber. Therefore it is highly unlikely that the two transactions' {{lastWriteDate}}s will ever be more than a network roundtrip time apart (a few milliseconds), so the impact of this bug is very minor. |