Reading

• Coulouris, et al: 12.4.2 - 12.4.8, 13.4-13.7

Project #1 Comments

Project #1 was returned today. Most people did well. But, I was in general disappointed with two things:

• Most people's reports stunk. They were a short paraphrase of the design in the handout. They didn't describe the design decisions that were encountered, what was traded off along the way, or the organization of the code itself.
  
  
• Most people weren't nearly ambitious enough. Most of the projects minimally met the spec -- but went no further.

This time, I graded things "softball-like". Next time, I will be much more demanding. In the future, a project that does no more than minimally meet the spec will be able to get no better than an 89. "A grades" will be reserved for those who do interesting things. I really think that those who get As should be the same people that turn in projects of which they, themselves, are really, really proud. A grades shouldn't be for those who just "turn the wheel" and get "done".

Specifically, it didn't seem like many people did things such as connection pooling, the rmi compiler, dynamic stub downloading, dynamic stub creation, &c. These are interesting things -- and would have made the project more fulfilling and more educational. They are examples of things that take a project from minimal -- to a complete package.

Secondly, the report is a real part of the project. This is expecially true of project #2, where it is expected to contain your results and analysis thereof.

But, don't feel badly. This project was a learning experience. And, I think almost everyone learned the ins and outs of implemeting and RMI -- so congratulations. Expectations are a learning process. Now you've got a better idea waht to expect. And, as for grades this time around -- I graded soft, with an "A-" for a minimal project that met the specs.

Safe Schedules

Transactions must execute as if in isolation. That doesn't necessarily prohibit concurrency among transactions -- it just implies that this concurrency shouldn't have any effect on the results or the state of the system. In fact, as long as the results and other state are the same as for some serial execution of the transactions, the transactions can be interleaved, executed concurrently, or btoh.

Transaction processing systems (TPSs) contain a transaction scheduler that dispatches the transactions and allows them to execute. This scheduler isn't necessarily FIFO, and it doesn't necessarily dispatch only one at a time. Instead, it tries to maximize the amount of work that gets done. One popular measure of the performance of a TPS is the number of transactions per second (TPS). Yes, unfortuantely, TPS is also its abbreviation.

In discussing the scheduler, it is helpful to ask the question, "What is a schedule?" It is an ordering of events. The transaction scheduler's job is to execute the indivdual operations that compose the transactions in an order that is efficient and preserves the property of isolation. As a result, it is the schedule of individual operations that is our concern.

Safe Concurrency: Serial Schedules and Serializability

A serial schedule is a schedule that executes all of the operations from one transaction, before moving on to the operations of another transaction. In other words the transactions are executed in series. An interleaved schedule is a schedule in which the operations of an individual transaction are executed in order with respect to the same transaction, but without the restriction that the transactions be scheduled as a whole. In other words, interleaving allows the scheduling of any operation, as long as the operations of the same transaction are not reversed.

Some interleaved schedules are safe, whereas other way result in violations of the isolation property. Safe interleaved schedules are known as serializable schedules. This is because an interleaved schedule is only safe if it is equivalent to a serial schedule -- that's why they call it serial-izable.

What did I mean when I wrote, is equivalent? An interleaved schedule is equivalent to a serial schedule, if transactions which containing conflicting operations are not interleaved. Operations are said to be conflicting if the results differ depending on their order.

This means that an interleaved schedule is serializable if, and only if, each pair of operations occurs in the same order as they would in some serial schedule.