10:18 a.m.
I think I made a mistake when User Storage Providers are importing into
local cache. Currently KeycloakSession.userLocalStorage() does not have
a cache in front of it. The LDAP and Kerberos providers call this to
determine if the user has been imported or not. The thing is, the user
may already be cached and I think there is a possibility of updating the
user (on demand resync) and getting stale cache entries. Also, we don't
want a database hit every time there is validation happening.
So, I'm going to figure out a way to have the cache front the
userLocalStorage() method too like we do for userStorage(). This will
require some refactoring of UserCacheSession. Not sure if that will
conflict with Marek's work.
Bill
12:42 p.m.
We're about to release 2.4.0.CR1. When will this be ready?
On 21 November 2016 at 17:18, Bill Burke <bburke(a)redhat.com> wrote:
I think I made a mistake when User Storage Providers are importing
into
local cache. Currently KeycloakSession.userLocalStorage() does not have
a cache in front of it. The LDAP and Kerberos providers call this to
determine if the user has been imported or not. The thing is, the user
may already be cached and I think there is a possibility of updating the
user (on demand resync) and getting stale cache entries. Also, we don't
want a database hit every time there is validation happening.
So, I'm going to figure out a way to have the cache front the
userLocalStorage() method too like we do for userStorage(). This will
require some refactoring of UserCacheSession. Not sure if that will
conflict with Marek's work.
Bill
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:57 p.m.
2.4.1
On 11/21/16 1:42 PM, Stian Thorgersen wrote:
We're about to release 2.4.0.CR1. When will this be ready?
On 21 November 2016 at 17:18, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
I think I made a mistake when User Storage Providers are importing
into
local cache. Currently KeycloakSession.userLocalStorage() does
not have
a cache in front of it. The LDAP and Kerberos providers call this to
determine if the user has been imported or not. The thing is, the
user
may already be cached and I think there is a possibility of
updating the
user (on demand resync) and getting stale cache entries. Also, we
don't
want a database hit every time there is validation happening.
So, I'm going to figure out a way to have the cache front the
userLocalStorage() method too like we do for userStorage(). This will
require some refactoring of UserCacheSession. Not sure if that will
conflict with Marek's work.
Bill
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
7:53 a.m.
Can you create a JIRA for this please?
On 21 November 2016 at 22:57, Bill Burke <bburke(a)redhat.com> wrote:
2.4.1
On 11/21/16 1:42 PM, Stian Thorgersen wrote:
We're about to release 2.4.0.CR1. When will this be ready?
On 21 November 2016 at 17:18, Bill Burke <bburke(a)redhat.com> wrote:
> I think I made a mistake when User Storage Providers are importing into
> local cache. Currently KeycloakSession.userLocalStorage() does not have
> a cache in front of it. The LDAP and Kerberos providers call this to
> determine if the user has been imported or not. The thing is, the user
> may already be cached and I think there is a possibility of updating the
> user (on demand resync) and getting stale cache entries. Also, we don't
> want a database hit every time there is validation happening.
>
> So, I'm going to figure out a way to have the cache front the
> userLocalStorage() method too like we do for userStorage(). This will
> require some refactoring of UserCacheSession. Not sure if that will
> conflict with Marek's work.
>
> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
2:09 a.m.
My stuff is already in. So the conflict shouldn't be there though.
The main thing is, that when you invalidate something, there needs to be
put new entry to "invalidationEvents" set, which are events to be sent
to other cluster nodes. The existing methods (eg.
registerUserInvalidation) are already doing it. This will work
regardless if cache is fronted with userStorage() or userLocalStorage() .
Marek
On 21/11/16 17:18, Bill Burke wrote:
I think I made a mistake when User Storage Providers are importing
into
local cache. Currently KeycloakSession.userLocalStorage() does not have
a cache in front of it. The LDAP and Kerberos providers call this to
determine if the user has been imported or not. The thing is, the user
may already be cached and I think there is a possibility of updating the
user (on demand resync) and getting stale cache entries. Also, we don't
want a database hit every time there is validation happening.
So, I'm going to figure out a way to have the cache front the
userLocalStorage() method too like we do for userStorage(). This will
require some refactoring of UserCacheSession. Not sure if that will
conflict with Marek's work.
Bill
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2956
days inactive
2957
days old
4 comments
3 participants
participants (3)
-
Bill Burke -
Marek Posolda -
Stian Thorgersen