----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Friday, 21 February, 2014 2:43:15 PM
Subject: Re: [keycloak-dev] caching
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.
Definitively, it's an interesting problem though ;)
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com