Hi, > I would rather not introduce the concept of the background read > to the DocumentStore. we already have the invalidation logic > and the 'maxCacheAge' in the DocumentStore.find() method. I > think we should rather revisit this mechanism and make sure it > works well with the requirements we have regarding cached reads. > a related issue was recently created by Julian, on the freshness > of DocumentStore.query(): OAK-3037. > > in my view, there is a more urgent need to clarify the current > DocumentStore API regarding consistency guarantees and think > about consistency requirements we have in the upper layer. the > DocumentNodeStore implementation should read with relaxed > consistency whenever possible and also be able to communicate this > to the DocumentStore implementation. >
If I understand correctly, the DocumentStore should try to keep up with storage (mongo, rdb, etc) as much as possible. And then we'd want DocumentNodeStore to query it with parameters guiding how recent results are expected (like the maxCacheAge in find method). Yup, that'd make sense. So, I'd then go ahead with inside MongoDocumentStore to track replication lag in the replica set. I guess it'd make sense to expose the polling interval as configuration parameter. Thanks for the inputs. --Vikas
