Super Fast Transactions in Low Milliseconds Using Cosmos DB and Redis

Intro
What problem are we solving? Cosmos does not support locking a record This means multiple updates can happen at once This is bad where the updates rely on reading a value and then updating it So I'll show you a way to implement locking for Cosmos
Based on that I've designed a population model that works on the population of kangaroos, humans and zombies in a particular city But, while I do the enormous and complex calculations, I need to be sure another process doesn't modify that cities information
So I need to be able to lock the data for a given city The demo code I'll show will demo . a SQL Server solution . a Cosmos solution for those days you really need a noSQL solution (that uses Cosmos SQL :-)
Locking in databases Because consistency is so important in databases, there are lots of different locks Locks can be applied to different resources Different types of locks have different effects
SQL Server Lock Types To get the consistency and performance balance correct, SQL Server has lots of different types of locks at least 10 last time I looked We'll discuss the 2 most important types for day to day use
Transactions So how do we control locking from our code Transaction Isolation levels give more control on what types of locks are taken
Timings Timings are critical Having a good view of timings in SQL Server is really hard But we're building our own locking
Application Insights App Insights tracks timings really well Super easy to understand what happens inside a request
Dependency Let's add a new class that extends the Application Insights Dependency collection If we make this implement Disposable, then we can let that complete the dependency magically for us
Lock Service Using RedLock.net Nuget package This wraps the Redis Cache distributed lock object nicely All we need to do is setup a RedLockFactory in our dependency injection
Use in a transaction Using RedLock we can take a distributed lock easily
Wait The wait parameter defines how long the caller is prepared to wait to obtain a lock This needs to be tuned to your use case
Retry This defines how often to try and get the lock If the resource was already locked, how often should another attempt be made to lock the resource This should be tuned based on the normal amount of time a lock should be held
Considerations (continued) In use cases where high contention is expected on an individual resource Care should be taken to handle the case where a lock was not obtainable within the wait time le what should happen if I can't get control of the resource fast enough?
LockToken, what's that for So our LockToken wraps the id of the resource we've locked. That means our code can check that we've got the correct resource locked before doing a write
Let's compare that to SQL Server So in SQL Server you do this in a Transaction You have to set the isolation level correctly or things won't work as you expect
Locking in general While the example here is Cosmos, there are many more use cases for distributed locking The demo here just shows how to make that easy And very debuggable using Application Insights