CacheItem expiration settings about cachemanager HOT 14 CLOSED

@HamitKARAHAN that's not supported.
You can only specify one expiration cache layer and cache configuration.
You can however have a configurations per object type for example,
You can override the configured expiration per cache item (which then gets applied to all layers though).

from cachemanager.

I wrote that quite long ago so I don't fully remember but the conclusion at the end was

And that's why I would say you should not try to do something like this, ever!

As you figured out yourself in your question. You would run into scenarios with stale data or you miss some operations potentially. If that's not acceptable (depends on your app, in some cases it might be ok to miss things), then, don't do it and instead, invest in your Redis cluster and make that almost impossible to fail.

fyi, this seems to become a Q&A, we have a discussion section for those kind of qustions.
Thanks

from cachemanager.

@HamitKARAHAN
If you cannot live with eventually consistency then don't use 2 layers of caching.
There is no guarantee that the invalidation works all the time, at least with the current implementation, which relies on redis Pub/Sub. Redis Pub/Sub can drop data and might time out during delivery or at any point actually.

If you have to 100% rely on the data, use only one Redis layer - you loose the performance gain but that will be 100% consistency...
if you can live with a short time where the data might be stale, use a second layer with a very short absolute expiration. Like a minute or less (based on your use case).

Regarding sending / receiving pub/sub messages from on 100s of machines, I honestly cannot tell how that would work.
You would have to scale the Redis server according to your needs and check if the network is good enough do handle all that backchannel traffic.
In theory it'll just work - it 100% depends on how big your Redis server/cluster is though I think.

from cachemanager.

Well, that is not 100% true ;)
First of all, you can, at any point, change the expiration of a cache item by retrieving it with GetCacheItem, changing the expiration and storing it via Put again.

var item = cache.GetCacheItem("key");            
cache.Put(item.WithExpiration(ExpirationMode.Sliding, TimeSpan.FromMinutes(1)));

I'm also not using the UtcNow of the creation date, for those cache providers which use DateTime, I use it the moment the item gets stored in the cache, so that the timeout is using the most accurate value.

Using a timespan for either sliding or absolute expiration is actually pretty common.
Redis for example also uses a timeout in seconds for the EXPIRE command for cache keys.

Another reason to use a timeout TimeSpan for absolute expiration instead of a fixed date is, that I can configure defaults for each cache handle, so that all cache items get the same expiration applied and you don't have to set it each time you Add an item. In this case, fixed DateTime values wouldn't work.

If you want to use a fixed date, you would just have to calculate the TimeSpan from it, for example like

DateTime a = DateTime.Now;
DateTime b = new DateTime(2015, 5, 30);

TimeSpan result = (b - a);

What we could do is, add two additional overloads for the methods which take expiration settings and allow to pass in either a DateTime or TimeSpan.
I don't like methods which take two parameters and one of them is optional, to do two different things; in my opinion this is bad design.

If you want, feel free to create a Pull request 😄

from cachemanager.

I agree that we could update the expiration of a cache item, but it seems a bit redundant and I believe that would be the main purpose of the sliding timeout.

As for the example you provided, I believe the feature should be named Fixed Timeout instead. This would be the same as you described that a fixed timeout without sliding (renewal). This feature would make perfect sense when configured as default value for the handles.

However, the name absolute timeout means (as least in my view) is a specific time that the item should expire. Which would be different, and yeah I actually used the exact same code you provided to mimic the behaviour.

I think two different method would make sense in this case, the ExpirationMode would not be even be necessary. However, this also means that the user cannot mix and match or have two separate expiration settings (not sure if its even a good use case for such?)

(Would prob need it if decide to have an additional feature to support Fixed timeout as you described)

from cachemanager.

I agree that we could update the expiration of a cache item, but it seems a bit redundant and I believe that would be the main purpose of the sliding timeout.

Just to be clear, the CacheManager handles sliding expiration for you, the example was just to show how to change the expiration settings of an item which might or might not already have expiration settings, e.g. you insert it with absolute expiration but change it later to sliding (for whatever reason one would want to do this) ;)

I think two different method would make sense in this case, the ExpirationMode would not be even be necessary

What do you exactly mean by "two different methods"? I think I don't really get what you mean

The ExpirationMode is also there for future additions, there could be another expiration mode...
And that I can remove expiration from the cache item. Otherwise there is no way to set "no expiration". If the cache default is sliding for example but I want to insert an item without expiration...
This would mean another method?
Mhm don't think this really makes things better ;)

from cachemanager.

By two different method I meant

Add(key, value, timespan)
Add(key, value, datetime)

With respect to the ExpirationMode, since no expiration is the default, by not passing the timespan or datetime you can assume the expiration would be none. So that covers the 3 currently supported ExpirationMode.

However, for making the method future proof. Perhaps an ExpiryPolicy class would make more sense since current implementation is limited to the parameter being a combination of timespan and mode. Or perhaps use/extend from CachItemPolicy defined by System.Runtime.Caching?

from cachemanager.

With respect to the ExpirationMode, since no expiration is the default, by not passing the timespan or datetime you can assume the expiration would be none

Not really because in this case it would take the default from the cache handle.

Regarding that CachePolicy objects, this is how System.Runtime.Caching is implemented, I don't really like it and I'm not using that approach on purpose. And I currently do not see any reason to change that.
We could add some quality of life overloads for using DateTime, so that you don't have to do the conversion to TimeSpan yourself.
But that's all I would change.

from cachemanager.

@bluefox I just checked in some expiration related changes.
Added methods to the cache interface so that you can directly set absolute, sliding expiration or remove expiration settings.
This basically does modify the cache item and puts it again with the modified expiration settings.

Also, the CacheItem now has the same functionality which can be manually used in conjunction with Put for example...

Let me know what you think

from cachemanager.

lobjCacheItem.WithAbsoluteExpiration(TimeSpan.FromMinutes(1)); is not removing key from redis. when I double check in the database after one minute, still the key persists. Any settings to be done ?

from cachemanager.

What do you mean the key still persists?
What's the ttl of the key?

from cachemanager.

@MichaCo Sir I am not still sure how to chain multiple Expiration Types. For example how to do

.WithExpiration(ExpirationMode.Sliding, TimeSpan.FromMinutes(5))
.WithExpiration(ExpirationModel.Absolute, TimeSpan.FromMinutes(60))

When i do this it takes only the last settings(absolute expiration in the above expamle). How to add this two or multiple expirations together? Thank you

from cachemanager.

@HamitKARAHAN that's not supported. You can only specify one expiration cache layer and cache configuration. You can however have a configurations per object type for example, You can override the configured expiration per cache item (which then gets applied to all layers though).

Thank you very much sir. I read your "What if Redis Fails" article in cachemanager.michaco.net. So I understood that we can switch memory cache when Redis fails and we can switch back to redis when connection restored. But i still cant understand if we switch to memory cache, and we have multiple instance, so how to handle with this? I mean if we are running memory cache when redis failed, and lets say our application runnig inside 4 machine in ec2, lets say a machine deleted or add item from memory cache. And how our other 3 machines will know this then delete or add same key from memory cache? Do we have a solution for this with CacheManager?

from cachemanager.

@MichaCo Hello sir, I didnt want to open new issue for this and thats why i am asking from here.
My problem is about how to use Redis and Memory cache together with CacheManager.
Let's say we are using Redis and Memory together, both are up and working healthy. When writing Redis, it will aslo write/delete/update memories of all machines for replying fast to our get requests, I get it. But i need to learn some answers which is I couldn't find in documents. If we run 200 machines, how long will it take for all machines to write/delete/update to memory? Is this a significant time? How long is the timeout? What if one or more machine gave error because of timeout? For example, what happens if 199 machines update data and 1 machine doesn't? It will still be holding stale data.
I am asking this because sometimes we put very important flags, keys and datas to redis. So that is why I need to know how this data is mapped to memories of my machines and any fallback when this job could't succeess.
Is there a solution you use to avoid such situations in CacheManager? Or maybe helpful methods you would recommend to us?

Thank you, regards

from cachemanager.