Indexed groups are retrieved from the group cache. As group caches may
possibly have stale entries (for example when in slave mode), we have to
be careful not to use outdated values. All code paths which referred to
the GroupIndexer correctly invalidated the group cache. Requiring the
cache evictions in other classes is a bit dangerous, though.
This situation becomes even worse with the recently added
GroupIndexer#reindexIfStale method. Whether the group index is stale is
determined by comparing the group stored in the index with the one
stored in NoteDb. For updating a stale index entry, we didn't ensure
that the group was freshly read from NoteDb. This means that users of
GroupIndexer#reindexIfStale which care about up-to-date values would
need to manually invalidate the cache, which would trigger an indexing
without the stale check, and hence make the call to
GroupIndexer#reindexIfStale obsolete. Alternatively, they would need to
accept outdated values without any guarantee when they are updated.
To prevent future errors due to missing cache invalidations and to allow
calling GroupIndexer#index and GroupIndexer#reindexIfStale even with
stale caches (e.g. in slave mode), we explicitly use a non-cached value
for indexing now.
As the necessity for manual cache evictions is removed, it makes sense
in other parts of the code to not indirectly trigger an indexing for a
group by evicting it from the cache but to explicitly call the indexer.
As a result, evicting an element from the cache doesn't need to trigger
an indexing anymore. Previously, this was a bit confusing as it wasn't
explicitly documented in Javadoc and only happened for GroupCache#evict
and GroupCache#onCreateGroup but not for GroupCache#evictRename. It
would also have created an infinite loop for the new eviction in the
indexer.
In addition, grouping several evictions into GroupCache#evict made it
complicated to get a non-cached value from
GroupCache#get(AccountGroup.UUID). If just the group UUID was available,
this required that a group had to be loaded first from the cache via
GroupCache#get(AccountGroup.UUID), then evicted, and then loaded again.
As the first loading doesn't necessarily need to retrieve a cached
value, the group might have been loaded twice from storage.
For AllGroupsIndexer, there was even a possibly unintended side-effect:
The cache invalidation triggered an indirect indexing for the group
before the group was retrieved from the cache and explicitly put in the
index. The adjusted code should avoid this situation by only doing all
interaction with the index in AllGroupsIndexer.
We also use the opportunity to add some tests for the GroupIndexer and
the adjusted behavior.
Change-Id: I0b281d7b72831d78462f7a7ac5e57a67d09d980b
adf3afaaf7