• I think I'm a bit confused as to what is bad and good in this case: concurrency can cause issues (so concurrency is bad), and we use locking to help (so locking is good)? Also what do we mean that "Serializability" improves concurrency without sacrificing isolation?

    Concurrency is not bad. In fact, it's essential. Can you imagine all 2400 Wellesley students having to take turns registering for classes, maybe in one long line? (How would people buy airline tickets?)

    And there's no reason not to allow Alice to register for English concurrently with Betty registering for Mandarin.

    However, just like in the real world, concurrency can cause races and anomalies, where the last ticket/seat is given to more than one person.

    We need to allow currency while mitigating its issues.

  • I was not able to copy the locking folder from the reading into my directory. I got the error that the folder does not exist.

    Ah. There was a typo (now fixed — thanks). Change the "cs340" to "cs304" and it works.

  • Does putting a lock/unlock around multiple statements turn them into one atomic transaction?

    Yes.

  • If I write-lock all the resources I am using, perform ~500 operation steps, and then commit and unlock all of them, would all of this be an atomic transaction?

    Yes.

  • Can the rollback command affect committed transactions?

    No. Rollback undoes non-committed updates.

  • I'm not sure if I understand the purposes of locking and isolation levels.

    Locking turns 2 or more updates into an atomic transaction: no one else can use that table until the set is done.

    The idea of isolation levels is to allow as much concurrency as possible, while reducing effects we don't want. Sometimes, we are willing to suffer some effects in order to allow more concurrency. Hence the different isolation levels.

  • Why can a transaction read an uncommitted write from an incomplete transaction when S2PL is not used? I thought values were local until they were committed? If uncommitted values can be accessed by dirty reads, then what does “commit” do?

    A different isolation levels, we can allow the reading of an uncommitted value. If you are displaying the number of seats left in a class or on a flight, it might be okay to display a count that includes someone who is booking some seats right now but hasn't (yet) committed.

  • I'm a little bit confused as to how transactions and locking are actually different/how these differences are achieved. Are there any issues that arise from transactions running in the before world?

    I'm a little confused by this question. The "before" world is before the transaction. Committing the transaction moves us (atomically) to the "after" world.

  • To prevent phantom tuples, can you just insert and lock the new tuple atomically?

    I don't think so, because different agents are doing the locking and insertion. Orit locks all records involving CS classes. Sohie inserts a new CS class. The new class is not in the set that Orit locked.

  • Can you prevent deadlock by having the operating system assign a priority value to each transaction (starting low for new transactions), detect deadlocks, and increment the priority of any transaction that is forced to reset to end a deadlock, so no transaction is starved for too long? Because the operating system, and not a transaction itself, is deciding whether a transaction with abort and try again, this should also prevent livelock?

    Priorities are a good way to prevent deadlock, though I don't know about your idea of incrementing priorities. We need to make sure we don't end up in a situation of circular priorities, which might happen if priorities can change.