Open Caching Mechanism

[chrisjenx]

This might be a little premature in the frameworks age, but are there any plans to open up the caching layer? I know this is something I can write on top of it, but the framework already provides mechanisms to invalidate the cache when a user does a write, something that is tricky to manage if your using Dao's directly.

Use case, Keeping, high read low write objects, E.g. a User object nearby in Memcache/Redis, this is an entity we almost always request for every request. (I think most applications would do something similar). That way we save having to hit the database for every request.

I'm not sure on the key/value interface, looking up and storing based on primary key would be more straight forward. I'm guessing caching queries that span multiple tables would not be advisable, if at all possible - esp as a change to a joined table in your query should invalidate the cached data. (maybe it already does that??)

interface SimpleCachingInterface {
  suspend fun <T> writeToCache(key: String, value: T)
  suspend fun <T> readFromCache(key: String, value: T)
  suspend fun <T> invalidateCache(keys: Array<String>)
}

Thoughts? I know Hibernate has something similar, not sure it can be used with Redis/Memcache though. http://doc.algotrader.ch/html/Hibernate_Sessions_and_Caching.html

[Tapac]

There is ImmutableCachedEntityClass which loads all entities to a memory and allows to change their state only via special function forceUpdateEntity. If you want to invalidate cache then you have to call expireCache.

This is not exactly what you need, but for some dictionary-like entities (almost read-only) this might boost your app performance.

[chrisjenx]

@Tapac not exactly what I need, but yeah a start, I mean memcache or redis would be preferable (even opening up that class with some abstract methods would be good start so I can call those services myself).
Also as you know if you have multiple instances, running local caches still means you have a 1 to 1 on DB reads to populate the cache, and if one instance invalidates the other instances would now have stale data.

So yeah would only work for literally read-only data.

Thanks though, wondering if I can expand on that example to create my own "layer" of sorts 👍

[Tapac]

You can create pub-sub channel with Redis to keep all instances up-to-date. I.e. when one of the instances change data it publishes "invalidate" event and all other instances call expireCache.

[chrisjenx]

I was thinking something like that too.

…

On Mon, 30 Jul 2018 at 02:42 Andrey.Tarashevskiy ***@***.***> wrote: You can create pub-sub channel with Redis to keep all instances up-to-date. I.e. when one of the instances change data it publishes "invalidate" event and all other instances call expireCache. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#349 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABHRsV606eQRUyhWvfgHhyoilarxpzJrks5uLtUagaJpZM4VcoYc> .

[lamba92]

There is ImmutableCachedEntityClass which loads all entities to a memory and allows to change their state only via special function forceUpdateEntity. If you want to invalidate cache then you have to call expireCache.

This definitely need to stay in the docs.
Just to be sure I understood ImmutableCachedEntityClass well, whenever I obtain an entity trought using it, if the entity gets modified i need to explicitely call MyEntity.forceUpdateEntity(listOf(myEntity)) right?
Can i modify the entity outside a transaction and later on call forceUpdateEntity inside a transaction?

[Hc747]

Have there been any updates on this?

[dosier]

I would love to see something like this too, the PR #883 looks good