Transactions Background Part 3: Local Snapshot Reads

Recent features in MongoDB such as multi-document ACID transactions have required foundational enhancements in MongoDB to enable them. One of these foundational changes is the ability to perform local snapshot reads.

Summary

For transactions to be effective it needs to be possible to look at the database at a particular point in time. That point in time consistency is made possible by low-level timestamps (from part 1) which identify data as part of a snapshot. The resources are tracked using logical sessions (from part 2).

Background

The traditional way for a long-running query to operate on the server was to keep acquiring data from a single database snapshot until the cursor was told to yield. In the process of yielding, the cursor state was saved and the locks and snapshot of the database were released.

On returning the lock was reacquired, a new snapshot was obtained, the cursor restored and the long-running query would carry on. This meant that the snapshot time could move forward with each yield.

Retaining the snapshot

Local Snapshot Reads simply do not release the snapshot or locks when yielding. The logical session from the client is used to record the locks and snapshot in the server and to track those resources to be released when an operation or transaction is complete. The use of the session also allows resource usage to be associated across all servers.

Using Local Snapshot Reads

To get the Local Snapshot Read behavior, a multi-document transaction has to be created within the client session with a ReadConcern of “snapshot”. With “snapshot” ReadConcern, all operations will take place against a consistent snapshot regardless of the number of distinct statements, network trips, or yield points . If the session the transaction is in is causally consistent, it’ll also be a snapshot that’s consistent with the previous operation transaction in the session.

Local Snapshot Reads and Transactions

Local Snapshot Reads offer transactions the ability to work from a point in time across the cluster. This means it can perform multi-document operations with an expectation that the snapshot time isn’t moving forward and is consistent.

In the next part of the series, we'll look at the Global Logical Clock in MongoDB and how it assists transactions.