[SERVER-46645] Make the UserCacheInvalidatorJob expect both OID and Timestamp Created: 05/Mar/20  Updated: 29/Oct/23  Resolved: 06/Mar/20

Status: Closed
Project: Core Server
Component/s: Security, Sharding
Affects Version/s: None
Fix Version/s: 4.4.0-rc0, 4.7.0

Type: Improvement Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Kaloian Manassiev
Resolution: Fixed Votes: 0
Labels: PM-1645-Milestone-3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.4
Sprint: Sharding 2020-03-09
Participants:

 Description   

As part of PM-1645 we are trying to move towards unifying all cluster-wide cached information to be stamped with configOpTime (or clusterTime). This has various benefits, but the most important of them is the ability to infer causality due to the ordering of opTimes.

In this model, the "cache generation" in the authorisation manager would be easier to think of as the opTime of when the last change to the auth data happened. This change makes the UserCacheInvalidatorJob expect both OID and Timestamp so that in later 4.4 releases we can change it to be a Timestamp without backwards compatibility implications.



 Comments   
Comment by Githook User [ 06/Mar/20 ]

Author:

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

Message: SERVER-46645 Make the UserCacheInvalidatorJob expect both OID and Timestamp

(cherry picked from commit deb72f3c5099582019a504e0477b96014fa7caf0)
Branch: v4.4
https://github.com/mongodb/mongo/commit/8b795f5a3bb048bd8e5c22f9c9e626036f8dfa6a

Comment by Githook User [ 06/Mar/20 ]

Author:

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

Message: SERVER-46645 Make the UserCacheInvalidatorJob expect both OID and Timestamp
Branch: master
https://github.com/mongodb/mongo/commit/deb72f3c5099582019a504e0477b96014fa7caf0

Generated at Thu Feb 08 05:12:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.