[keycloak-dev] caching

Bill Burke bburke at redhat.com
Fri Feb 21 09:43:15 EST 2014

On 2/21/2014 9:13 AM, Stian Thorgersen wrote:
> I agree that there are headaches involved in a distributed cache, but they will always be an issue if you have a cache.
> You're going to need to have some mechanism to invalidate entries in the cache whenever there's an update to the db. Infinispan provides various mechanisms to expire unused items, and it also has multiple clustering modes where the most interesting to us would be invalidation not replication. In invalidation mode the actual data isn't sent on the network, so should be less risky with regards to security.

Not sending data is the reason I want to do invalidation.  But again, 
even in that scenario, we have to figure out how to secure Infinispan. 
I'd also like to keep us using HTTP as a primary transport.

> I would also hope that Infinispan supports OpenShift, or plans to soon.
> Non-JPA cache I agree with is the better option, but it may prove to be a fair amount of work, and possible error-prone. I've done this in the past and it was a real PITA to write and maintain.

I've done it too.  Its not so much of a pain if you're only reading from 
the cache and you're doing invalidation.

If a Keycloak non-jpa cache API existed, then we could also put it in 
front of non-JPA backends, like if we decided to make Picktelink IDM API 
our primary storage backend.

BTW, I don't want to roll my own cache, I'd just like to use a 
local-only deployment of Infinispan or something and write our own 
remote invalidation protocol.

Anyways, this is a few months away, IMO before we even start to consider 
to work on this.  Just something to think about.

Bill Burke
JBoss, a division of Red Hat

More information about the keycloak-dev mailing list