[keycloak-dev] caching

[Bill Burke]

I don't want to require a distributed cache.  It may make both securing 
this cache, configuring, and deploying it much more complicated than we 
want it to be.  Especially in an environment like Openshift.  Don't you 
think?  Plus there's things that can be stored in a non-JPA cache.  i.e. 
you can pre-calculate role mappings, scope mappings, access grants. 
Then all you have to do is marshall the tokens into json and sign them.

As far as huge deployments goes, define huge?  Even a realm with 1 
million users would probably be around 10GiG, which is very easy to 
handle for most modern databases.

On 2/21/2014 4:14 AM, Stian Thorgersen wrote:
> 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
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com