Posts

.NET Synchronisation APIs - Part 2 - Out-of-Process Synchronisation

Introduction This is the second in a series of posts on .NET synchronisation: In-process synchronisation Out-of-process synchronisation on the same machine (this post) Distributed synchronisation This time I'm going to talk about using the synchronisation APIs I described on the first post , dedicated to in-process synchronisation, but in out-of-process context, meaning, to synchronise different processes, not threads. This can be achieved out of the box with three synchronisation objects: Mutex Semaphore EventWaitHandle  (remember, parent class of AutoResetEvent and ManualResetEvent ) These objects follow the same pattern: open (fails if doesn't exist) or try to open an existing object by its name.  For a synchronisation object to be available system-wide it needs a name and can have fine-grained permissions on Windows systems. I will cover permissions more to the end of this post. I will also be covering an additional technique that can also be used for synchronisation: s h...

.NET Synchronisation APIs - Part 1 - In-Process Synchronisation

Introduction This is the first in a series of posts on .NET synchronisation. I will cover: In-process synchronisation (this post) Out-of-process synchronisation on the same machine Distributed synchronisation In .NET, in-process synchronisation mechanisms are used to restrict access to shared resources and manage concurrency in multi-threaded applications. The mechanisms I'm going to present on this post can be used only for in-proc code, for synchronising threads, meaning, they cannot be used to synchronise multiple processes, on the same or on different machines - I will write more posts on these subjects and link them here. Here I will be using the terms "locking" and "synchronising on" interchangeably, to mean the same thing. I won't go into too much theory, but thread synchronisation exists for preventing: Race conditions: two threads trying to modify the same data simultaneously Data corruption: data shared by two or more threads becomes inconsistent ...

EF Core State Validation

Introduction How many times have you tried to save changes to your context only to get an exception about validation problems, like a required property being null ? I certainly have, and because of this, I came up with a solution to figure out what is happening. I will also provide some possible solutions for the problem of fully validating an entity using the Data Annotations API  (a post on general validation with Data Annotations here ). State Validation All the entities that are currently tracked by a DbContext have some state known to the context. This state includes: The entity's state ( State ) in regards to persistence ( Modified , Added , Deleted , Unchanged ) Each property's values ( Property ), both current ( Current ) and original ( Original ) The entity itself ( Entity ) Any navigation properties ( References , Navigations ) So, we can iterate through each tracked entry by means of the Entries , Entries<T> , or Entry methods: var entity = ...; var ent...