The AuthorizationManager maintains a pool of User* objects. Callers which need to access to a particular User* will fetch it from the pool and bump a ref-count. Periodically, the AuthorizationManager may discover that an update has occurred which pertains to a particular User*. When this occurs, it will mark the User* as invalid by settingan Atomic variable on the object, and remove it from the pool. Future callers will no longer be able to acquire the invalid User* from the pool, and will have to create a new instance from disk. Past callers will eventually check and discover that their User* is invalid, discard it, and fetch a new instance from the pool. Once the User*'s refcount reaches 0, it will be freed.

This pool allows concurrent, eventually consistent, access to point in time copies of read-only data. Once a User* is checked out, no locks are required to access it. Once a User* is invalidated, its consumers will eventually figure out they should stop using it. The pool maintains a generation counter, which can be advertised by config servers. A mongos operating off a different generation count than its config server will know that its cache is inconsistent and should be purged.

This pattern would be useful to manage the lifetimes of other types of objects in a cluster. We should extract the pool from the AuthorizationManager, and templatize it to operate off generic types.

Additionally, the pool should not track and hand out bare pointers. Instead it should expose managed RAII pointers. Callers should not be required to perform manual ref-count manipulation.