Super Fast Transactions in Low Milliseconds Using Cosmos DB and Redis

Super Fast Transactions in Low Milliseconds Using Cosmos DB and Redis

NDC Conferences via YouTube Direct link

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 …

14 of 18

14 of 18

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 …

Class Central Classrooms beta

YouTube videos curated by Class Central.

Classroom Contents

Super Fast Transactions in Low Milliseconds Using Cosmos DB and Redis

Automatically move to the next video in the Classroom when playback concludes

  1. 1 Intro
  2. 2 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…
  3. 3 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 s…
  4. 4 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 …
  5. 5 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
  6. 6 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 f…
  7. 7 Transactions So how do we control locking from our code Transaction Isolation levels give more control on what types of locks are taken
  8. 8 Timings Timings are critical Having a good view of timings in SQL Server is really hard But we're building our own locking
  9. 9 Application Insights App Insights tracks timings really well Super easy to understand what happens inside a request
  10. 10 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
  11. 11 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
  12. 12 Use in a transaction Using RedLock we can take a distributed lock easily
  13. 13 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
  14. 14 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 …
  15. 15 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 wha…
  16. 16 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
  17. 17 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
  18. 18 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

Never Stop Learning.

Get personalized course recommendations, track subjects and courses with reminders, and more.

Someone learning on their laptop while sitting on the floor.