Package org.keycloak.models.cache.infinispan

Class RealmCacheSession

  • All Implemented Interfaces:
    CacheRealmProvider, ClientProvider, ClientScopeProvider, GroupProvider, RealmProvider, RoleProvider, Provider, ClientLookupProvider, ClientScopeLookupProvider, GroupLookupProvider, RoleLookupProvider
    public class RealmCacheSession
extends Object
implements CacheRealmProvider
    - the high level architecture of this cache is an invalidation cache. - the cache is manual/custom versioned. When a model is updated, we remove it from the cache which causes an invalidation message to be sent across the cluster. - We had to do it this way because Infinispan REPEATABLE_READ wouldn't cut it in invalidation mode. Also, REPEATABLE_READ doesn't work very well on relationships and items that are not in the cache. - There are two Infinispan caches. One clustered that holds actual objects and a another local one that holds revision numbers of cached objects. Whenever a cached object is removed (invalidated), the local revision cache number or that key is bumped higher based on a local version counter. Whenever a cache entry is fetched, this revision number is also fetched and compared against the revision number in the cache entry to see if the cache entry is stale. Whenever a cache entry is added, this revision number is also checked against the revision cache. - Revision entries are actually never removed (although they could be evicted by cache eviction policies). The reason for this is that it is possible for a stale object to be inserted if one thread loads and the data is updated in the database before it is added to the cache. So, we keep the version number around for this. - In a transaction, objects are registered to be invalidated. If an object is marked for invalidation within a transaction a cached object should never be returned. An DB adapter should always be returned. - After DB commits, the objects marked for invalidation are invalidated, or rather removed from the cache. At this time the revision cache entry for this object has its version number bumped. - Whenever an object is marked for invalidation, the cache is also searched for any objects that are related to this object and need to also be evicted/removed. We use the Infinispan Stream SPI for this. ClientList caches: - lists of clients are cached in a specific cache entry i.e. realm clients, find client by clientId - realm client lists need to be invalidated and evited whenever a client is added or removed from a realm. RealmProvider now has addClient/removeClient at its top level. All adapaters should use these methods so that the appropriate invalidations can be registered. - whenever a client is added/removed the realm of the client is added to a listInvalidations set this set must be checked before sending back or caching a cached query. This check is required to avoid caching an uncommitted removal/add in a query cache. - when a client is removed, any queries that contain that client must also be removed. - a client removal will also cause anything that is contained and cached within that client to be removed Clustered caches: - There is a Infinispan @Listener registered. If an invalidation event happens, this is treated like the object was removed from the database and will perform evictions based on that assumption. - Eviction events will also cascade other evictions, but not assume this is a db removal. - With an invalidation cache, if you remove an entry on node 1 and this entry does not exist on node 2, node 2 will not receive a @Listener invalidation event. so, hat we have to put a marker entry in the invalidation cache before we read from the DB, so if the DB changes in between reading and adding a cache entry, the cache will be notified and bump the version information. DBs with Repeatable Read: - DBs like MySQL are Repeatable Read by default. So, if you query a Client for instance, it will always return the same result in the same transaction even if the DB was updated in between these queries. This makes it possible to store stale cache entries. To avoid this problem, this class stores the current local version counter at the beginningof the transaction. Whenever an entry is added to the cache, the current coutner is compared against the counter at the beginning of the tx. If the current is greater, then don't cache. Groups and Roles: - roles are tricky because of composites. Composite lists are cached too. So, when a role is removed we also iterate and invalidate any role or group that contains that role being removed. - any relationship should be resolved from session.realms(). For example if JPA.getClientByClientId() is invoked, JPA should find the id of the client and then call session.realms().getClientById(). THis is to ensure that the cached object is invoked and all proper invalidation are being invoked.
    Version:
    $Revision: 1 $
    Author:
    Bill Burke