<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: What happens when you write to same Delta table from two different clusters at the same time? in Data Engineering</title>
    <link>https://community.databricks.com/t5/data-engineering/what-happens-when-you-write-to-same-delta-table-from-two/m-p/22351#M15304</link>
    <description>&lt;P&gt;Delta Lake uses&amp;nbsp;&lt;A href="https://en.wikipedia.org/wiki/Optimistic_concurrency_control" alt="https://en.wikipedia.org/wiki/Optimistic_concurrency_control" target="_blank"&gt;optimistic concurrency control&lt;/A&gt;&amp;nbsp;to provide transactional guarantees between writes. Under this mechanism, writes operate in three stages:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Read: Reads (if needed) the latest available version of the table to identify which files need to be modified (that is, rewritten).&lt;/LI&gt;&lt;LI&gt;Write: Stages all the changes by writing new data files.&lt;/LI&gt;&lt;LI&gt;Validate and commit: Before committing the changes, checks whether the proposed changes conflict with any other changes that may have been concurrently committed since the snapshot that was read. If there are no conflicts, all the staged changes are committed as a new versioned snapshot, and the write operation succeeds. However, if there are conflicts, the write operation fails with a concurrent modification exception rather than corrupting the table as would happen with the write operation on a Parquet table.&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Check out this &lt;A href="https://docs.databricks.com/delta/concurrency-control.html" alt="https://docs.databricks.com/delta/concurrency-control.html" target="_blank"&gt;documentation&lt;/A&gt;. &lt;/P&gt;</description>
    <pubDate>Fri, 18 Jun 2021 21:40:01 GMT</pubDate>
    <dc:creator>Ryan_Chynoweth</dc:creator>
    <dc:date>2021-06-18T21:40:01Z</dc:date>
    <item>
      <title>What happens when you write to same Delta table from two different clusters at the same time?</title>
      <link>https://community.databricks.com/t5/data-engineering/what-happens-when-you-write-to-same-delta-table-from-two/m-p/22350#M15303</link>
      <description />
      <pubDate>Fri, 18 Jun 2021 21:14:30 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/what-happens-when-you-write-to-same-delta-table-from-two/m-p/22350#M15303</guid>
      <dc:creator>Anonymous</dc:creator>
      <dc:date>2021-06-18T21:14:30Z</dc:date>
    </item>
    <item>
      <title>Re: What happens when you write to same Delta table from two different clusters at the same time?</title>
      <link>https://community.databricks.com/t5/data-engineering/what-happens-when-you-write-to-same-delta-table-from-two/m-p/22351#M15304</link>
      <description>&lt;P&gt;Delta Lake uses&amp;nbsp;&lt;A href="https://en.wikipedia.org/wiki/Optimistic_concurrency_control" alt="https://en.wikipedia.org/wiki/Optimistic_concurrency_control" target="_blank"&gt;optimistic concurrency control&lt;/A&gt;&amp;nbsp;to provide transactional guarantees between writes. Under this mechanism, writes operate in three stages:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Read: Reads (if needed) the latest available version of the table to identify which files need to be modified (that is, rewritten).&lt;/LI&gt;&lt;LI&gt;Write: Stages all the changes by writing new data files.&lt;/LI&gt;&lt;LI&gt;Validate and commit: Before committing the changes, checks whether the proposed changes conflict with any other changes that may have been concurrently committed since the snapshot that was read. If there are no conflicts, all the staged changes are committed as a new versioned snapshot, and the write operation succeeds. However, if there are conflicts, the write operation fails with a concurrent modification exception rather than corrupting the table as would happen with the write operation on a Parquet table.&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Check out this &lt;A href="https://docs.databricks.com/delta/concurrency-control.html" alt="https://docs.databricks.com/delta/concurrency-control.html" target="_blank"&gt;documentation&lt;/A&gt;. &lt;/P&gt;</description>
      <pubDate>Fri, 18 Jun 2021 21:40:01 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/what-happens-when-you-write-to-same-delta-table-from-two/m-p/22351#M15304</guid>
      <dc:creator>Ryan_Chynoweth</dc:creator>
      <dc:date>2021-06-18T21:40:01Z</dc:date>
    </item>
  </channel>
</rss>

