CSEP 545 Transaction Processing for E-Commerce |
||||||||||||||||||||||||||||||
Philip A. Bernstein ( | ), (425)706-2838 | |
http://www.research.microsoft.com/~philbe |
Meeting Time
Tuesday 6:30 - 9:20 PM, January 4 - March 8 |
A one-hour project demonstration, March 7-18 (exact dates TBD) |
An exam during final exam week, March 14-18 (exact date TBD) |
1. (live) Microsoft Building 113 room 1159, phone (425)722-5657 |
2. (via video at UW) Allen, room 305. |
If you're attending at Microsoft building 113: |
|
Teaching Assistant
Michael Gubanov ( | ), (206) 543-5143 | |
Office: Allen 370 |
Web Site
http://www.cs.washington.edu/education/courses/csep545/05wi
CSEP 545 Mailing Lists
http://mailman.cs.washington.edu/mailman/listinfo/csep545
Please subscribe immediately to this mailing list
There are also two mailing lists to support the class project:
http://mailman.cs.washington.edu/mailman/listinfo/csep545-java
http://mailman.cs.washington.edu/mailman/listinfo/csep545-csharp
You should subscribe to the appropriate mailing list.
Lecture Outline
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 class time will be consumed by discussions of assignments and projects. |
1. Introduction (textbook, Chapter 1) |
2. Shadowing-based recovery, in support of the project. Handout (not in textbook). |
3. Database Concurrency Control, Part 1 (textbook, revised Chapter 6 (handout) Sections 1-4) |
4. Database Recovery (textbook, Chapter 8) |
5. Basic Application Servers, in support of the project. |
6. Two-Phase Commit (textbook, Chapter 9) |
7. Database Concurrency Control, Part 2 (textbook, revised Chapter 6 Sections 4 - 11) |
8. Queuing (textbook, Chapter 4) |
9. Replication (textbook, Chapter 10) |
10. Application Servers (textbook, Chapter 2, Chapter 3 Sections 3.1 - 3.3) |
11. Advanced topics: T.B.D. |
There are no specific 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 queries). |
There are three components to your grade: |
1. There will be an term exam in class, probably on February 8. |
2. There will be a second exam during the week of March 14. |
3. You will do a substantial two-person project. |
Your grade will be a weighted sum of the two exams (50%) and project (50%). |
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 recommend that you make a serious attempt at solving them, since it's an 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 many interacting parts. The goal of the project is to deepen your understanding of how the parts fit together. It involves implementing 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, the basic application, 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. |
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. |
Except in rare cases, people will work in groups of two. It helps you, to have design discussions with a partner. And it helps us, to make our reviewing load manageable. |
Due dates: |
|
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. |