Race condition in pesimistic concurrency management

[Narvalex]

I will always grow with new Guids, without any cleaning being performed in the concurrent dictionary of semaphores by Guid

[gautema]

Do you actually get an exception? They should be removed from the dictionary when the are removed from the MemoryCache. Line 27 in CacheRepository is where the callback is registered.

https://github.com/gautema/CQRSlite/blob/master/Framework/CQRSlite/Cache/CacheRepository.cs#L27

[Narvalex]

You are right. Thanks

[Narvalex]

I think there is still a chance of a race condition. If the lock is removed just after a thread grabs it, a second thread will create a new entry in the dictionary and there will be two concurrent threads racing for the same stream. Makes any sense?

[gautema]

While this is so unlikely it will probably never happen, it will just behave like a when the regular repository gets two commands on the same time. If an exception is thrown, it will be removed from the cache again

[Narvalex]

Ok, I am agree that there is mechanism to recover from it, but the pesimistic lock is a bit optimistic, just a bit indeed. Maybe we should point out that, since Im sure there are guys that might use this approach for high contention scenarios where there is not a mechanism to recover from a failure.