CHAPTER 8 Transactions and Versioning
297
•
If a user's read transaction commits before a concurrent write transaction
does, and that user begins a new read transaction, the version remains the
same.
•
If a read transaction commits after a concurrent write transaction does, any
new transaction, whether read-only or read/write, uses a new version.
Figure 8-4 on page 296 is an example of the first instance. Both of User 2's
transactions use the same version as User 1's transaction began with, because
that is the latest committed version of the data.
Figure 8-5 shows what happens in the second instance. This time, User 2's first
read transaction (Tr1) commits after User 1's write transaction. When User 2's
second transaction (Tr2) begins, it uses a new version that reflects the
committed data from User 1.
Figure 8-5: Effect of read transaction committing
Hold cursors span transactions
The only exception to the rule that transactions always use the latest committed
version is in transactions that use hold cursors. Hold cursors are treated
differently because they can span transactions. See “Cursors in transactions”
for details.
Summary of Contents for Adaptive Server IQ 12.4.2
Page 1: ...Administration and Performance Guide Adaptive Server IQ 12 4 2 ...
Page 16: ...xvi ...
Page 20: ...Related documents xx ...
Page 40: ...Compatibility with earlier versions 20 ...
Page 118: ...Troubleshooting startup shutdown and connections 98 ...
Page 248: ...Importing data by replication 228 ...
Page 306: ...Integrity rules in the system tables 286 ...
Page 334: ...Cursors in transactions 314 ...
Page 396: ...Users and permissions in the system tables 376 ...
Page 438: ...Determining your data backup and recovery strategy 418 ...
Page 484: ...Network performance 464 ...
Page 500: ...System utilities to monitor CPU use 480 ...
Page 514: ...Characteristics of Open Client and jConnect connections 494 ...
Page 536: ...Index 516 ...