Instructor: Philip A. Bernstein, philbe@microsoft.com, (425) 936-2838
http://www.research.microsoft.com/~philbe/
Meeting Time: Wednesday 6:30 – 9:20 PM, January 3 – March 7.
Final exam and project demonstration during the week of March 12
Locations: (live) Microsoft Redmond West F/1002, phone 703-6132
(video)
EE1 003
Textbook: “Principles of Transaction
Processing for the System Professional,”
by Philip A. Bernstein and Eric Newcomer, Morgan Kaufmann Publishers, 1997
Teaching Assistants: Ashish Gupta (akgupta@cs.washington.edu),
Pradeep Shenoy (pshenoy@cs.washington.edu)
Mailing List: cse593@cs.washington.edu.
To subscribe, send mail to majordomo@cs.washington.edu
with the following in the body of the mail:
subscribe
cse593
Assignments and Solutions
Lecture 3 Handout (Revised Chap. 6)
Below is the list of course topics. The exact order of topics may vary slightly from this sequence. Also, the mapping of topics to course meetings is hard to predict, since topics are of different lengths and some meetings will include discussions of assignments and projects.
1. Introduction (textbook, Chapter 1)
2. Transaction Processing Monitors (textbook, Chapter 2)
3. Database Concurrency Control (textbook, revised Chapter 6 (handout) )
4. Database Recovery (textbook, Chapters 7 and 8)
5. Two-Phase Commit (textbook, Chapter 9)
6. Transaction Processing Communications (textbook, Chapter 3)
7. Queuing (textbook, Chapter 4)
8. Replication (textbook, Chapter 10)
9. Advanced Transaction Models and Workflow
There are no particular prerequisites for the course, besides having a good general understanding of software systems. It’s also helpful to have some knowledge of SQL (to be able to write simple selection and join queries).
There are three components to your grade:
Your grade will be a weighted sum of the mid-term (15%), project (40%), and final exam (35%), plus an extra 10% weight to your best of the 3.
There will be weekly assignments for much of the course, covering material that’s easiest to learn by solving structured problems. The solution to each assignment will be discussed in lecture one week after the assignment is handed out. The assignments will not be graded. However, we strongly recommend that you make a serious attempt at solving them, since it’s a very effective way to learn the material. Some of the exam questions will be minor variations of some of the assignment questions.
Transaction processing is a systems engineering problem, with lots of interacting parts. The goal of the project is to deepen your understanding of how the parts fit together. There are two projects to choose from:
1.
Implement a
distributed transaction system in Java or C#.
The server will allow customers to make/cancel/query travel
reservations, will allow airlines to add/cancel/modify flight information, and
will allow hotels and car rental agencies to post room and car
availability. We will provide clients,
the interface the clients expect, a lock manager, and a general design
framework for the (ultimately distributed) server. Students will build mechanisms for persistence, recovery, and
two-phase commit. The transaction
system will concurrently support multiple clients and multiple servers.
2. Design and implement a travel reservation TP application using the Microsoft product set: SQL Server and COM+. Keep it simple enough to get an end-to-end system working well enough to run a demo. In particular, keep the user interface very simple. We expect the top projects to include additional features, which will be described in the project handout, such as IIS and ASPs, security roles, and multi-database transactions.
For both projects, make sure you have a solid working solution of basic features, and save a snapshot of that code, before adding more advanced features. Only a short write-up is required to summarize what you have done and to provide a blueprint of the code, as long as the code is readable. A final demonstration is required.
Due dates:
· January 10 – Email message telling which project you selected and who you will be working with.
· January 24 – Milestone One. You should have at least a trivial skeleton running. Hand that in, plus a one or two page summary of your design.
· February 21 – Milestone Two. You should have at least half of the final project features running. Hand that in, with enough of a write-up that we can understand what’s in your code and what you have accomplished.
· March 7 – Final Project is due.
Milestone reports are largely for your benefit, to ensure you’re pacing the work and to check that you’re on the right track. Milestones will be reviewed but not graded. If you do not hand in a milestone, and we later find that you’re making some serious design errors, it will be your problem for not having given us the chance the flag the error early enough for you to fix it.