Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Transaction 4
This transaction wasn’t completed at the time of system failure and must therefore be rolled back. In
effect, it never happened from a row-data perspective. The user would have to reenter any data, and any
process would need to start from the beginning.
Transaction 5
This one is no different from Transaction 4. It appears to be different because the transaction has been
running longer, but that makes no difference. The transaction was not committed at the time of system
failure and must therefore be rolled back.
Implicit Transactions
Primarily for compatibility with other major RDBMS systems, such as Oracle or DB2, SQL Server
supports (it is off by default, but can be turned on if you choose) the notion of what is called an implicit
transaction. Implicit transactions do not require a BEGIN TRAN statement — instead, they are automatically
started with your first statement. They then continue until you issue a COMMIT TRAN or ROLLBACK
TRAN statement. The next transaction then begins with your next statement.
Implicit transactions are dangerous territory and are well outside the scope of this book. Suffice to say
that I highly recommend that you leave this option off unless you have a very specific reason to turn it
on (such as compatibility with code written in another system).
Locks and Concur rency
Chapter 14: Transactions and Locks
Concurrency is a major issue for any database system. It addresses the notion of two or more users each
trying to interact with the same object at the same time. The nature of that interaction may be different
for each user (updating, deleting, reading, inserting), and the ideal way to handle the competition for
control of the object changes depending on just what all the users in question are doing and just how
important their actions are. The more users — more specifically, the more transactions — that you can
run with reasonable success at the same time, the higher your concurrency is said to be.
In the OLTP environment, concurrency is usually the first thing we deal with in data and it is the focus of
most of the database notions put forward in this book. (OLAP is usually something of an afterthought —
it shouldn’t necessarily be that way, but it is.) Dealing with the issue of concurrency can be critical to the
performance of your system. At the foundation of dealing with concurrency in databases is a process
called locking.
Locks are a mechanism for preventing a process from performing an action on an object that conflicts with
something already being done to that object. That is, you can’t do some things to an object if someone
else got there first. What you can and cannot do depends on what the other user is doing. Locks are also
a means of describing what is being done, so the system knows if the second process action is compatible
with the first process or not. For example, 1, 2, 10, 100, 1,000, or whatever number of user connections
the system can handle, are usually all able to share the same piece of data at the same time as long as
they all want the record on a read-only basis. Think of it as being like a crystal shop: Lots of people can be
in looking at things — even the same thing — as long as they don’t go to move it, buy it, or otherwise
change it. If more than one person does that at the same time, you’re liable to wind up with broken crystal.
That’s why the shopkeeper usually keeps a close eye on things and will usually decide who gets to
handle things first.
433