[keycloak-dev] top-level cache strategy

[Stian Thorgersen]

Sounds good to me

A related issue is that I think we should split the model into two:

* Model - realm, apps, clients, roles, scopes
* Users - profiles, credentials, role mappings

I think there's quite a few benefits to this:

* Model is pretty complex (31 tables now)
* Model db will in most cases be small, and could be stored in config files
* Users db will in most cases be large
* Would make it easier to shard (as we replicate the model, while we can shard users)
* Would make it easier to upgrade - model can be updated more frequently with less impact on upgrade, while we should strive to not change users db (if users have 20 million entries it'll take time to upgrade)
* Users may want to implement the Users SPI themselves (and we can provide alternatives), but they are far less likely going to want to change the model

This is an issue I think it would be good to have a hangout about though. Also, not sure if it's viable at all for 1.0.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 20 June, 2014 4:23:17 PM
> Subject: [keycloak-dev] top-level cache strategy
> 
> Last week I put in a cache that sits on top of our model API.  I'm going
> to continue with it and *not* use any caching implementation like
> Infinispan.  Here's what it will look like:
> 
> * Provider SPI for cache implementation
> * Simple hand made cluster cache for Keycloak as follows:
> - Cache is currently loaded on demand
> - Cached objects are read-only and are invalidated at end of transaction
> if changed.
> - ConcurentHashMaps for non-user information.
> - LRU cache for UserModel and Credentials.  This will be a synchronized
> LinkedHashMap.
> - Cluster nodes will be defined manually in keycloak-server.json under
> the cache scope.
> - Simple secure invalidation REST API
> - Simple secure ping REST API
> - If a remote invalidation or ping fails, then cache will be wiped and
> disabled until a ping can be re-established.
> 
> I don't think any of this is much work.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>