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
http://bill.burkecentral.com