[keycloak-dev] caching changes

[Marek Posolda]

Should this be done for user's cache too? Couldn't it happen that same 
user is concurrently updated by 2 threads?

Also wonder about scenario like:
- 2 admin users are editing realm at the same time
- Admin1 enables user's registration for the realm and click "update"
- Admin2 changed access token timeout and then click "update" . AFAIK at 
this point, he overwrites the change by admin1 because we send whole 
realm representation in the request.

Do we want to address this? Or is this rather a corner case?

Marek


On 12/02/16 19:47, Bill Burke wrote:
> I'm still working on stuff, but here is a summary of things so far:
> * ConcurrenyTest is passing
> * Caching implementation is now a pessimistic locking style based on
> versions.  Locking never happens on reads, only writes.  There are two
> caches.  One cache holds the actual data, and is pretty much a vanilla
> invalidation cache.  The other cache olds versioning information and is
> a local-only cache and just is an id->version map.  Given an id, what is
> the current version of it.  Hopefully, the implementation makes sure
> that you never are able to add or obtain a stale version of an object
> from the cache.  Locking happens for updates.  At the end of a
> transaction, all registered invalidations are iterated on, and a version
> cache lock on that id is obtain.  The db is updated, and after that the
> locks are released.  A lock is also obtained whever something is added
> to the cache.  Again a lock is only obtained on the version cache, so
> any reads will never block.
> * KeycloakTransactionManager now has an enlistPrepare method.
> * There is a new RealmProvider.getClientByClientId() method. Clients now
> have a clientId "index" in the cache.
> * There is a new RealmProvider.removeClient() method.  This was needed
> to support getClientByClientId()
>
> Some other things that were done:
> * Unnecessary @JoinTables were removed for certain @OneToMany relationships.
> * getId() will no longer cause a DB query if you are invoking on a
> reference to a JPA adapter
> * RealmModel.getClients() and getClientNameMap() is no longer used to
> implement getClientByClientId() :)
> * CachedRealm now stores PrivateKey, PublicKey, and Certificate in a
> transient variable.  We were actually unmarshalling from the cached pem
> format every time these things were access, which is like few times per
> login.
>
> Next steps:
> * Create a client list cache for each realm.  Currently, if you
> add/remove a client, this invalidates the realm cache and its doing a
> big query for each client.
> *  Do some profiling to see if there's other things we can do.
>