Sybase 12.4.2 manual Timing of commits on read transactions affects versions, 296

Overview of transactions and versioning

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.

296