<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Transactions on Chen Kai Blog</title><link>https://www.chenk.top/en/tags/transactions/</link><description>Recent content in Transactions on Chen Kai Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 28 Apr 2024 09:00:00 +0000</lastBuildDate><atom:link href="https://www.chenk.top/en/tags/transactions/index.xml" rel="self" type="application/rss+xml"/><item><title>Databases (7): Distributed Transactions — 2PC, Saga, and Why Consensus Is Hard</title><link>https://www.chenk.top/en/databases/07-distributed-transactions/</link><pubDate>Sun, 28 Apr 2024 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/databases/07-distributed-transactions/</guid><description>&lt;p>Everything we covered about transactions in Article 3 assumed a single database server: one machine, one transaction log, one lock manager. When your data spans multiple machines—through sharding, using microservices with separate databases, or replicating with strong consistency—you face the hardest problem in distributed systems: how do you get multiple machines to agree?&lt;/p>
&lt;hr>
&lt;h2 id="the-distributed-transaction-problem" class="heading-anchor">The Distributed Transaction Problem&lt;a href="#the-distributed-transaction-problem" class="heading-link" aria-label="Permalink to this section" title="Copy link to this section">#&lt;/a>
&lt;/h2>&lt;p>Consider an e-commerce system with separate services for orders and inventory, each with its own database:&lt;/p></description></item><item><title>Databases (3): Transactions and Concurrency — ACID, Isolation Levels, and Locking</title><link>https://www.chenk.top/en/databases/03-transactions-and-concurrency/</link><pubDate>Sun, 21 Apr 2024 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/databases/03-transactions-and-concurrency/</guid><description>&lt;p>Every application that handles money, inventory, or any state that matters eventually hits a concurrency bug. Two users buy the last item in stock. A bank transfer debits one account but crashes before crediting the other. A report reads half-updated data and produces nonsense numbers. Transactions exist to prevent these failures, and understanding how they work is non-negotiable for anyone building production systems.&lt;/p>
&lt;hr>
&lt;h2 id="what-is-a-transaction" class="heading-anchor">What Is a Transaction?&lt;a href="#what-is-a-transaction" class="heading-link" aria-label="Permalink to this section" title="Copy link to this section">#&lt;/a>
&lt;/h2>&lt;p>A transaction is a group of operations that the database treats as a single unit. Either &lt;strong>all&lt;/strong> operations succeed, or &lt;strong>none&lt;/strong> of them do.&lt;/p></description></item></channel></rss>