C# IDistributedCache Multi-Thread Approach Question

[firey]

I have a project that users send data to a server written in C#. The users have the ability to send an action against an object. To reduce DB Traffic, I am using IDistributedCache to hold the instance of the main object, as it also allows for cross-server shared caching.

I am running into an issue with multiple threads where two people send an action to the server. Each thread calls the same function which loads up the instance of the object from the IDistributedCache (using _cache.getAsync(,....)).  This results in each thread effectively ending up with it's own instance of the object.  The issue is that whatever thread finished last, ends up writing that instance of the object back to the cache, thus losing any changes made in the other thread as the modified object isn't what the current thread has in it's memory.

 

I was thinking that I could use a standard hashtable/dictionary and just reference the object directly ie: objdict[objid].actions.add(action). That way I have one instance in memory that all threads would have the same state for. However, doing it that way I have no way to support distribution like I do with the IDistributedCache.

 

I am wondering if anyone has dealt with this, or has any idea of how can I make it so that both threads get the same reference to the object (akin to using the dictionary), but keep it so it can be split across servers (distributed). 

[Jonathans]

I worked on a project a few years ago where we had a similar scenario. We had similar issues and many solutions put forward for tests. Included queuing the object instance between threads so that the instance was ONLY active in one thread.

The final solution though, didnt go this route, but what was done was to take the principal of a shared whiteboard. By this i mean each thread gets a new instance of the 'core' instance, but with triggers to each instance to push through from the child instance to the core, and from the core push those changes to each subsequent child.

This solution worked but did also suffer from the same race condition, but on a smaller basis, that was resolved by discarding any changes to the sub-properties at the lowest level on a rule of Who Makes Changes First keeps them.

 

Don't think this will help you much, but i hope it helps give you an idea...

[Jonathans]

  On 22/03/2019 at 12:51, Jonathans said:

I worked on a project a few years ago where we had a similar scenario.

Expand  

Also we were using a state engine of sorts, not IDistributedCache, but principal was similar

[+virtorio MVC]

Without knowing the specifics of the system and data, it sounds like you shouldn't be caching the data if your actions are modifying it.