Re: [keycloak-dev] caching changes

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. >