stian at redhat.com
Fri Feb 21 04:14:41 EST 2014
Initially I think using Infinispan as a 2nd level cache for JPA would be the way to go. It provides all of this stuff with the minimum fuzz. Later if we can't tune it enough, we could use Infinispan directly.
For really huge deployments I we'd probably need support for sharding as well.
----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 February, 2014 8:54:01 PM
> Subject: [keycloak-dev] caching
> What's been brewing around in my mind awhile is optimization of the
> token service. There's no reason everything couldn't be cached in
> memory for each token service deployed. Even millions of users could be
> cache. Memory is cheap.
> The cache should be local only and only the Token Service should use it.
> Admin console, or any other update operations would cause invalidation
> of each cache on each machine by sending invalidation messages. These
> invalidation messages would be REST invocation secured by Keycloak of
> course! If we wanted to put in any guarantees, we could back these
> invalidation messages with HornetQ or something.
> Bill Burke
> JBoss, a division of Red Hat
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
More information about the keycloak-dev