---------------- Atomic Transactions ----------------

This is a BIG topic; worthy of a course (databases)

Stable storage: Able to survive "almost" anything

    For example can survive a (single) media failure

Transactions:    ACID

    Atomic

        To the outside world it happens all at once.

        It's effects are never visible while in progress

        Can fail (abort) then none of its effects are ever visible

    Consistent

        Does not violate any system invariants when completed

            Intermediate states are NOT visible from Atomic

        System dependent

    Isolated

        Normally called serializable

        When multiple transactions are run and complete the effect is
        as if they were run one after the other in some (unspecified)
        order, i.e. you don't get a little of one and then a little of
        another.

    Durable

        Often called permanance

        Once a transaction commits, its effects are permanant

        Stable storage often used

HOMEWORK 11-13

Nested Transactions
       
    May want to have the child transactions run concurrently.

    If a child commits, its effects are now available WITHIN the
    parent transaction

        So children serialized AFTER the child see the effects

    But if a child commits and then the parent (subsequently) aborts
    the effects of the child are NOT visible outside.

---------------- The following is by eric freudenthal ----------------

Concurrency Control 
    the synchronization primitives required to build transactions

    Locking: 
        use mutex, explore granularity issues.

        two phase locking (acquire all locks, do transaction, release
        locks).  Quit if a lock is unavailable.

        This scheme works well when contention is low, may lead to
        starvation.  

        In-order lock aquisition avoids live/deadlock.

    Optimistic:
        Resembles two-phase commitment - don't save files until all
        mods made.  May need to abort & retry.

            indirection makes this faster (copy & mod reference structure
            rather than data itself

        Good parallelism when works.

        Deadlock free.

    Timestamp consistency:
        Data (files) marked with date of last transactions read &
        write.  Transactions fail if they try to set times
        inconsistently.  

Preventing Deadlock (while providing synchronization as building blocks)

    Both communication channel & resource deadlocks are possible.

        Communication channel deadlock can be caused by running out of
        buffers.
            Important to get this right, for it's hard to negotiate 
            if the communication channels are blocked.
    What to do:
        ostrich - works most of the time if contention is low
        detect - easier
        prevent - make structurally impossible
        avoid - carefully write program so it can't happen

    Detecting deadlock
        centralized manager
            risk of outdated information - false deadlock
                fix with lamport's time stamps & interrogation