Filter
Top Products
Overview of transactions and versioning
296
In other words, every transaction begins with a snapshot of the data in a reliable
state. The snapshot of the data that you see when you issue a query does not
change, even if another user is updating the table you are reading. For example,
in Figure 8-4, when User 1’s write transaction begins, it uses the
customer table
version that was committed most recently. User 2’s transaction begins after
User 1 has begun writing, but before User 1 commits. Therefore, User 2’s first
transaction (Tr1) does not see any of User 1’s updates. User 2’s second
transaction begins after User 1 commits, so it sees all of User 1’s changes.
Figure 8-4: Transactions use committed data
The data that a writer sees changes only according to the changes he or she
makes; no other transaction can change what a writer sees until the writer’s
transaction commits. For example, in Figure 8-4, User 1 inserts some data,
then does a query, and then deletes some data. Those query results reflect the
insertions that User 1 has just made.
Other transactions that begin after User 1’s transaction begins but before it
commits see the version of the data from the time User 1’s transaction begins.
They can’t see the latest changes, because those changes were not yet
committed. As soon as User 1’s transaction commits, new transactions see User
1’s changes.
Timing of commits on read transactions affects versions
While a read transaction cannot affect what an existing write transaction sees,
committing a read transaction does have implications for other transactions.