Wondered why transactions can carry with them deadlocks and race conditions? Then this video maybe is for you. We are not going to discuss exactly how deadlocks and race conditions occur. Instead we are talking about a way to avoid them completely using Project Arrow's STM. Make sure to follow this video until the end to learn interesting aspects of it and how transactions work in this way. I hope you enjoy the video and I hope you find it useful for your every day transactional endeavors. As usual, until the next video, be sure to stay tech, keep programming, be kind and have a good one everyone! br br PS: Given the intense scheduling of the channel and the amount of work, the Wednesdays sessions, under the pilot project, have moved to Thursdays 8PM CET. The reason for this is to see if that scheduling reaches more people given generic availability to watch premieres a on this day. br br --- br br Chapters: br br 00:00:00 Start br 00:00:36 Intro br 00:00:39 Software Transactional Memory (STM) br 00:02:04 Explaining Software Transactional Memory in Project Arrow br 00:02:24 Talking about "Architectural Support for lock-free data-structures" br 00:02:58 Back to STM br 00:04:23 Another run through "Architectural Support for lock-free data-structures" br 00:04:42 Explaining Transaction cases br 00:07:55 Optimistic Concurrency Control br 00:08:31 Introduction to the example br 00:08:44 Talking about the "8 reasons why you should... or should not choose Ktor from a Spring Comparison Perspective" br - br 00:13:14 Talking about the "8 reasons why you should... or should not choose Ktor from a Spring Comparison Perspective" br - br 00:14:47 Explaining the requestDocking method - Simple Common Transaction br 00:17:32 Talking about past 5 coroutine videos: br - br - br - br - br - br 00:20:24 Explaining the refuel method - Simple Common Transaction Highlighting Conflict br 00:23:37 Talking about the Dispatcher.