Bug: TenanAwareKey vs not tenant aware keys in cache #14
Conversation
| return new HzCache(map, config.getTenantProvider()); | ||
| ServerCache hzCache = new HzCache(map); | ||
| if (config.getTenantProvider() != null) { | ||
| return new TenantAwareCache(hzCache, new TenantAwareKey(config.getTenantProvider())); |
There was a problem hiding this comment.
@rbygrave I would suggest to move that code to Ebean and remove cache handling form the plugin completely. It acts as a proxy and converts all keys to be tenant-aware.
Unfortunately, we have to do some more or less expensive copy operations on getAll/putAll/removeAll methods.
Note: this kind of bug is also present in other cache plugin(s), e.g. here: https:/ebean-orm/ebean-ignite/blob/master/src/main/java/io/ebean/ignite/IgCache.java#L49
| @Override | ||
| public Map<Object, Object> getAll(Set<Object> keys) { | ||
| Map<Object, Object> keyMapping = new HashMap<>(); | ||
| keys.forEach(k -> keyMapping.put(key(k),k)); |
There was a problem hiding this comment.
We have to convert the keyset (e.g. 1234, 5678) to a tenantaware key (1234:1, 5678:1)
and we have to do remove the tenant-info after we get the result form the cache.
this could be probably done by tmp.forEach((k,v)-> ret.put(((CacheKey) k).key, v)) as it should be always a cacheKey
There was a problem hiding this comment.
ret.put(((CacheKey) k).key ...
Yes, that looks better to me.
|
So yes I agree, TenantAwareCache should move into ebean-api or ebean-core. |
|
I see that you currently do a lot of refactoring and releaseing all modules |
Do what? Move TenantAwareCache I am thinking? |
|
FYI: I am adding TenantAwareCache ... and making the appropriate adjustments ... |
|
Refer: ebean-orm/ebean#2638 |
|
Fixed by a0fbfb2 |
|
@rbygrave thank you for the fix. We are going to migrate to ebean 13 next week |
Hello @rbygrave ,
@rPraml and I tested our application in a multi tomcat environment with hazelcast and we got some problems by caching (login of a user).
From an user-password entity we had 2 entries in the cache map: one with the UUID as key (e.g. 1234) and the second one used the TenantAwareKey (e.g. 1234:1, :1 as the tenant information) --> Our next query wanted to load the entity from the cache but it got the "wrong" one without the tenant information which was outdated (--> our login was not successful because it used the old password).
@rPraml implemented a temporary solution that works in our application.