stian at redhat.com
Fri Feb 21 09:48:50 EST 2014
----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at 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
More information about the keycloak-dev