Is there a way to lock a concurrent dictionary from being used

Question

I have this static class

static class LocationMemoryCache
{
    public static readonly ConcurrentDictionary<int, LocationCityContract> LocationCities = new();
}

My process

1. Api starts and initializes an empty dictionary
2. A background job starts and runs once every day to reload the dictionary from the database
3. Requests come in to read from the dictionary or update a specific city in the dictionary

My problem

If a request comes in to update the city

1. I update the database
2. If the update was successful, update the city object in the dictionary
3. At the same time, the background job started and queried all cities before I updated the specific city
4. The request finishes and the dictionary city now has the old values because the background job finished last

My solution I thought about first

Is there a way to lock/reserve the concurrent dictionary from reads/writes and then release it when I am done?

This way when the background job starts, it can lock/reserve the dictionary only for itself and when it's done it will release it for other requests to be used.

Then a request might have been waiting for the dictionary to be released and update it with the latest values.

Any ideas on other possible solutions?

Edit

1. What is the purpose of the background job?

If I manually update/delete something in the database I want those changes to show up after the background job runs again. This could take a day for the changes to show up and I am okay with that.

2. What happens when the Api wants to access the cache but its not loaded?

When the Api starts I block requests to this particular "Location" project until the background job marks IsReady to true. The cache I implemented is thread safe until I add the background job.

3. How much time does it take to reload the cache?

I would say less then 10 seconds for a total of 310,000+ records in the "Location" project.

Why I chose the answer

I chose Xerillio's answer because it solves the background job problem by keeping track of date times. Similar to a "object version" approach. I won't be taking this path as I have decided that if I do a manual update in the database, I might as well create an API route that does it for me so that I can update the db and cache at the same time. So I might remove the background job after all or just run it once a week. Thank you for all the answers and I am ok with a possible data inconsistency with the way I am updating the objects because if one route updates 2 specific values and another route updates 2 different specific values then the possibility of having a problem is very minimal

Edit 2

Let's imagine I have this cache now and 10,000 active users

static class LocationMemoryCache
{
    public static readonly ConcurrentDictionary<int, LocationCityUserLogContract> LocationCityUserLogs = new();
}

Things I took into consideration

1. An update will only happen to objects that the user owns and the rate at which the user might update those objects is most likely once every minute. So that reduces the possibility of a problem by a lot for this specific example.
2. Most of my cache objects are related only to a specific user so it relates with bullet point 1.
3. The application owns the data, I don't. So I should never manually update the database unless it's critical.
4. Memory might be a problem but 1,000,000 normalish objects is somewhere between 80MB - 150MB. I can have a lot of objects in memory to gain performance and reduce the load on the database.
5. Having a lot of objects in memory will put pressure on Garbage Collection and that is not good but I don't think its bad at all for me because Garbage Collection only runs when memory gets low and all I have to do is just plan ahead to make sure there is enough memory. Yes it will run because of day to day operations but it won't be a big impact.
6. All of these considerations just so that I can have an in memory cache right at my finger tips.

Answer 1

I would suggest adding a UpdatedAt/CreatedAt property to your LocationCityContract or creating a wrapper object (CacheItem<LocationCityContract>) with such a property. That way you can check if the item you're about to add/update with is newer than the existing object like so:

public class CacheItem<T>
{
    public T Item { get; }
    public DateTime CreatedAt { get; }
    // In case of system clock synchronization, consider making CreatedAt 
    // a long and using Environment.TickCount64. See comment from @Theodor
    public CacheItem(T item, DateTime? createdAt = null)
    {
        Item = item;
        CreatedAt = createdAt ?? DateTime.UtcNow;
    }
}

// Use it like...
static class LocationMemoryCache
{
    public static readonly
        ConcurrentDictionary<int, CacheItem<LocationCityContract>> LocationCities = new();
}

// From some request...
var newItem = new CacheItem(newLocation);
// or the background job...
var newItem = new CacheItem(newLocation, updateStart);

LocationMemoryCache.LocationCities
    .AddOrUpdate(
        newLocation.Id,
        newItem,
        (_, existingItem) =>
            newItem.CreatedAt > existingItem.CreatedAt
            ? newItem
            : existingItem)
    );

When a request wants to update the cache entry they do as above with the timestamp of whenever they finished adding the item to the database (see notes below).

The background job should, as soon as it starts, save a timestamp (let's call it updateStart). It then reads everything from the database and adds the items to the cache like above, where CreatedAt for the newLocation is set to updateStart. This way, the background job only updates the cache items that haven't been updated since it started. Perhaps you're not reading all items from DB as the first thing in the background job, but instead you read them one at a time and update the cache accordingly. In that case updateStart should instead be set right before reading each value (we could call it itemReadStart instead).

Since the way of updating the item in the cache is a little more cumbersome and you might be doing it from a lot of places, you could make a helper method to make the call to LocationCities.AddOrUpdate a little easier.

Note:

• Since this approach is not synchronizing (locking) updates to the database, there's a race condition that means you might end up with a slightly out-of-date item in the cache. This can happen if two requests wants to update the same item simultaneously. You can't know for sure which one updated the DB last, so even if you set CreatedAt to the timestamp after updating each, it might not truly reflect which one was updated last. Since you're ok with a 24 hour delay from manually updating the DB until the background job updates the cache, perhaps this race condition is not a problem for you as the background job will fix it when run.
• As @Theodor mentioned in the comments, you should avoid updating the object from the cache directly. Either use the C# 9 record type (as opposed to a class type) or clone the object if you want to cache new updates. That means, don't use LocationMemoryCache[locationId].Item.CityName = updatedName. Instead you should e.g. clone it like:

// You need to implement a constructor or similar to clone the object
// depending on how complex it is
var newLoc = new LocationCityContract(LocationMemoryCache[locationId].Item);
newLoc.CityName = updatedName;
var newItem = new CacheItem(newLoc);
LocationMemoryCache.LocationCities
    .AddOrUpdate(...); /* <- like above */

• By not locking the whole dictionary you avoid having requests being blocked by each other because they're trying to update the cache at the same time. If the first point is not acceptable you can also introduce locking based on the location ID (or whatever you call it) when updating the database, so that DB and cache are updated atomically. This avoids blocking requests that are trying to update other locations so you minimize the risk of requests affecting each other.

Answer 2

No, there is no way to lock a ConcurrentDictionary on demand from reads/writes, and then release it when you are done. This class does not offer this functionality. You could manually use a lock every time you are accessing the ConcurrentDictionary, but by doing so you would lose all the advantages that this specialized class has to offer (low contention under heavy usage), while keeping all its disadvantages (awkward API, overhead, allocations).

My suggestion is to use a normal Dictionary protected with a lock. This is a pessimistic approach that will result occasionally to some threads unnecessarily blocked, but it is also very simple and easy to reason about its correctness. Essentially all access to the dictionary and the database will be serialized:

1. Every time a thread wants to read an object stored in the dictionary, will first have to take the lock, and keep the lock until it's done reading the object.
2. Every time a thread wants to update the database and then the corresponding object, will first have to take the lock (before even updating the database), and keep the lock until all the properties of the object have been updated.
3. Every time the background job wants to replace the current dictionary with a new dictionary, will first have to take the lock (before even querying the database), and keep the lock until the new dictionary has taken the place of the old one.

In case the performance of this simple approach proves to be unacceptable, you should look at more sophisticated solutions. But the complexity gap between this solution and the next simplest solution (that also offers guaranteed correctness) is likely to be quite significant, so you'd better have good reasons before going that route.