Databases Reference
In-Depth Information
locks on rows for longer than necessary, active transactions can prevent other
users from updating data, which ultimately can reduce throughput and cause
concurrency issues. In this case, you may want to commit the
Select
statements
in intervals (after every five
Select
statements, for example) so that locks are
released in a timely manner.
In addition, be aware that leaving transactions active consumes database
memory. Remember that the database must write every modification made by a
transaction to a log that is stored in database memory. Committing a transaction
flushes the contents of the log and releases database memory. If your application
uses transactions that update large amounts of data (1,000 rows, for example)
without committing modifications, the application can consume a substantial
amount of database memory. In this case, you may want to commit after every
statement that updates a large amount of data.
How often your application performs transactions also determines when
you should commit them. For example, if your application performs only three
transactions over the course of a day, commit after every transaction. In contrast,
if your application constantly performs transactions that are composed of
Select
statements, you may want to commit after every five
Select
statements.
Isolation Levels
We will not go into the details of isolation levels in this topic, but architects
should know the default transaction isolation level of the database system they
are using. A
transaction isolation level
represents a particular locking strategy
used in the database system to improve data integrity.
Most database systems support several isolation levels, and the standards-
based APIs provide ways for you to set isolation levels. However, if the database
driver you are using does not support the isolation level you set in your applica-
tion, the setting has no effect. Make sure you choose a driver that gives you the
level of data integrity that you need.
Local Transactions Versus Distributed Transactions
A
local transaction
is a transaction that accesses and updates data on only one
database. Local transactions are significantly faster than distributed transactions
because local transactions do not require communication between multiple
databases, which means less logging and fewer network round trips are required
to perform local transactions.
