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(a)redhat.com>
To: keycloak-dev(a)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
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev