10:23 a.m.
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
10:37 a.m.
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(a)redhat.com>
To: keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:52 a.m.
On 6/20/2014 11:37 AM, Stian Thorgersen wrote:
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
You forgot User Sessions too. Which would be the 3rd split, IMO.
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.
We should seriously considering getting it into 1.0. Its good to get
these things right before major releases. Once 1.0 goes out, we're
going to be supporting a lot more users.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3842
days inactive
3842
days old
2 comments
2 participants
participants (2)
-
Bill Burke -
Stian Thorgersen