<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Optimistic Locking on Nalar</title>
    <link>https://nalar.dev/tags/optimistic-locking/</link>
    <description>Recent content in Optimistic Locking on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 19 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/optimistic-locking/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Version Columns Turn Database Updates into Conditional State Transitions</title>
      <link>https://nalar.dev/version-columns-turn-database-updates-into-conditional-state-transitions/</link>
      <pubDate>Sat, 19 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/version-columns-turn-database-updates-into-conditional-state-transitions/</guid>
      <description>&lt;p&gt;A database client can read a row, spend time computing a change, then issue an &lt;code&gt;UPDATE&lt;/code&gt; after another transaction has already changed the same row. If the final statement identifies the row only by its primary key, the later write can replace state derived from the intervening transaction without any visible conflict.&lt;/p&gt;&#xA;&lt;p&gt;A version column changes that boundary. The client reads both the application state and a revision value, then includes that revision in the update predicate. The database accepts the write only while the stored revision still matches the state the client observed.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
