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.
JBoss, a division of Red Hat
More information about the keycloak-dev