Why .NET's memory cache is kinda flawed 

Thank you for the info and the reference to LazyCache. If you think about it, the 'standard' MemoryCache way of working does work in the same way as a distributed cache so if you intend to scale up and move from in-memory to distributed cache you might get less 'surprises'.

"Cache rules everything around me". 😄 Cool Easter Egg.

I currently do something like this by using ConcurrentDictionary. I don't use this pattern a lot, and I'm hesitant to adding another dependency but I'll have a look.

I'm using LazyCache in my project as well. It helps me dealing with concurrent issues in asynchronous situations with ease.

This is really useful! I discovered LazyCache by watching this video and I wish I found it years ago. Thanks Nick!

The pitfalls of optimistic concurrency. You can solve this issue with MemoryCache with extensions. You just have to evict the entry if the result produces an exception. Great to see you bringing this up.

MemoryCache actually uses a ConcurrentDictionary, so you're right to say it's the same thing.

Very sad that this LazyCache does not implement existing IMemoryCacheinterface and it can simply override implementation. :(

6:37 WOW! I noticed that Wu Tang Clan reference 👏

Wow. I never knew this was an issue with concurrentDictionary and memoryCache (that uses the concurrentDictionary). I had so many issues with a caching on a project about 2 years ago with memoryCache. I was going crazy trying to understand the problem and this never occurred to me. Also had issues on a component that used concurrentDictionary. This is all good stuff to play with. I no longer work for that company, but I do some consultant work for them. If they ever ask to return to that project I now know what I'll be testing to fix those problems. Thanks for the knowledge.

Thank you. Great video, as always. It's weird that Lazy cache developed their own interface instead of using Microsoft.Extensions.Cache.Abstractions. Thats a deal breaker for me. As I try to keep away from anything that cannot be replaced using DI. I would like to know if the alternate solution exists

I trust AsyncLazy from the MS package more tbh. Create it in the factory instead of the final value

The reason behind is that locking the factory call is dangerous as it can cause the deadlock, if factory call somehow calls method that locke the same semaphore. Callbacks are always dangerous to lock.

Awesome vid Nick, but I think I spotted a typo: * "Caches ruins everything around me"

Great content as usual! I didn't know about this concurrency issue.

For async operations that I need to be atomic, I use an "async lock" that I made, it's basically a IDisposable mutex wrapper, which I can use like using(await MyUtilsFacade.Lock("some_non_interned_text_key")) { } I found this particularly useful because I don't have to create lambdas, I don't get closuring problems and I can move values to and from the locked region without worrying about crazy behavior. It automatically creates/deletes the mutexes by key and frees the key strings passed when they're no longer in use, so I don't get "Interned guid strings" bloating application's RAM over long periods of time. (Because that's also a problem I faced, the normal "lock" keyword wasn't working well because not only I cant await within lock, the strings passed to it were sometimes different references even when they're equal, so I used string.intern and that caused my application to bloat overtime because interned strings are apparently never freed)

Thoughts on FusionCache? Operates as a memory cache, but can optionally use a distributed cache as your application grows.

Useful video as always!

Thanks!

Hey Nick, any plans on signalR or any real time programming videos in the future?

I don't think that verbosity in the DI is really necessary? You can just use AddSingleton(); AddSingleton(); EDIT: No - I had missed that the CachedWeatherService takes an IWeatherService, not a WeatherService.

Dropping a like for the Wu Tang reference. Also for the useful lesson. Dope.

I'd like to see the DI video that Nick told in the video, anyone knows which video is?

Also, memory cache doesnt have preeviction callback (callback before cache is expired) so that cache is automatically renewed lets say every 1hour. This feature had "old" net framework memorycache!

thanks you for share it

What's the equivalent of "GetOrCreateAsync" (IMemoryCache) for IDistributedCache?

I didnt really understand what was the behaviour we expected to see with the built in memory cache example or how it was different from what actually happened. It feels like you went over that part a little too fast

Thanks a lot for the video 🤓👌

what camera do you use to record video?

Hey Nick, any opinion on Akavache?

When you were changed the parameter of GetCurrentWeatherAsync from city to entry.Key.ToString()! you said it was to avoid a closure. Do you have a video going into detail about how closures impact the app and when/how to avoid them?

"... get the money! Dollar dollar bill yaaaalll!" 😅

Ahahhaa :D I enjoyed this video so much! I think he just graduated from blah & blah and wonders what a wheel is.

For the HTTP scenario would be better do use the Response Cache or implement the lazy cache package?

Hi Nick, can you do a video about autofac?

Hey, Nick. When you'll do CV review?

"Weather doesn't change really fast unless you are in London.." 😂😂 You should go back to Greece, awesome culture, food and weather😂✌️

I wonder how Proto Actor would be for this. Granted, it is a much more complicated solution for this "simple" problem.

Even though MemoryCache is using ConcurrentDictionary internally, the exact method GetOrCreateAsync behaves like it's not thread safe because it's actually isn't - sadly it's an extension method which is implemented as two operations TryGetValue and then CreateEntry instead of one atomic one. And this is pretty annoying, because every other methods are thread safe, while this the most important one isn't. The ConcurrentDictionary, however, has a method GetOrAdd, which is actually thread safe. Pretty sure ConcurrentDictionary would work just fine with its GetOrAdd method (no async unfortunately), returning the same results as LazyCache. The only thing, that delegate "_ => Interlocked.Increment(..)" can indeed perform few times in concurrent environment before getting into the cache, which may in theory lead to all results being 2 or 3 instead of 1. But still it would be consistent.

I don't exactly get when this becomes a problem in the context of cache. Can anyone provide an example? obviously having an extra package is unwanted thing, so I need to understand when exactly should I care about this

Every time I see caching code implementing these cross cutting patterns I long for Postsharp.Caching! Damn licence fees

Whaaaaat?!!! The concurrent dictionary also suffers from this?? Oh god..

did you accidentally leak your api key at the beginning of the video?

I wish I were better in this. i'm a flawed man. I want to learn caching, but simpler. I wonder if there are videos that can do that. All i want to learn is to cache some data from a db for some time for each user so when the refresh the app don't go to the db to get the same data again. response caching or memory caching, I don't know when to use it correctly.

Is it just that the LazyCache locks the factory method internally ?

In my app i need to be able to invalidate items in cache manually from code not only based on duration. Is it possible with lazy cache ?

Which IDE is this?

Hi nick

its all fun and games, until your company decides to build their own caching solution.......

What's the history behind always using "69" as a value in all your videos?

Dollar dollar bill y'all

Lol Wutang

Not sure why you are providing a solution to a poorly implemented method.