COM1317 -- Spring 2002
Transaction Processing Systems
College of Computer Science, Northeastern University
Professor Robert P. Futrelle
NEWS May 31st:
Study guide for the FINAL EXAM now posted.
Assignment #3 was posted May 15th.
May 5th: The website has been brought up-to-date, especially the
which is now complete through to the end of the course.
Another assignment, #3, will be assigned and posted at some point.
The material on the website is seriously out-of-date.
What counts is what I go over in class. I'm preparing
the midterm for this Thursday (5/2) and will be going over that
material on Monday and Tuesday in preparation for the test.
After that we will go over Chap. 7 briefly and then really
focus on Chap. 8 -- Durability, the 'D' in ACID, as well
as Chap. 9 which explains how transactions can commit
safely and correctly even when they're distributed across
multiple resource managers. These important topics will
keep us busy for the remainder of the quarter.
Assignment #2 is posted. Follow the Assignments link to
the left. Topic is isolation -- schedules and locking.
Due as hardcopy at the beginning of class, Monday the 29th.
Assignment #1 was posted. Follow the Assignments link to
the left. The Syllabus is not yet prepared. For now, you should
have thoroughly read Chapters 1 and 2. By the end of this week
you should have read Chapter 3 one time through.
To the students in this course:
Transaction processing in database systems is quite an amazing process, when you get right
down to it. It assures that even when many transactions are happening simultaneously
(or apparently so) that they don't interfere with one another, or worse, interact in
an inconsistent way. More interesting still is that database systems that handle transactions
properly cannot ever perform an inconsistent or partial transaction, even in the face of machine or
network failure or even disk failure. While a database system is running, you can pull the plug
on it. When it recovers, all of the transactions that were in progress when the plug was pulled
are restored to
a state in which the transactions did not occur at all (and must be redone) or they completed
successfully and correctly. The classic example is transferring money between two accounts.
You would think that if the money was removed from one account and then the plug was pulled before
the money could be added to the other, that the result would be wrong -- that money would have disappeared
from the first account and never appear in the second. But transaction processing systems are
designed so this cannot happen!
Because of the complex nature of transaction processing this course will cover the ideas in detail
but will not include programming projects. So your task will be to learn the concepts and terminology
and be able to do the problems, quizzes and exams by answering questions using the correct terminology
and concepts and drawing the appropriate diagrams when necessary.
The textbook we will use in this course is a basic one by acknowledged experts in
Principles of Transaction Processing for the Systems Professional
by Philip A. Bernstein (Microsoft) and Eric Newcomer (Iona, Waltham, MA).
I will supplement the text with various other material, such as a discussion of the
SQL statements that control transactions explicitly and implicitly.
Since we will not have projects, the course will be built around assignments and exams, with the
exams by far the most important. Consider the assignments as your way of preparing for the tests.
There will be three small quizzes, a Midterm and a Final Exam.
Many of you will be involved with databases in your work in the future. It is far easier to
work with databases if you really understand what's going on inside them, rather than just
knowing some external "user-level" manipulations. This course will be a big step towards
giving you the critical inside knowledge that will help you succeed in various endeavors
in the future.
-- Professor Futrelle