=====
CS 325 - Week 14 Asynchronous Material
=====

=====
"TODAY" WE WILL
=====
*   announcements
*   continue: Transaction Management and Concurrency Control - Part 2
*   Some useful string- and date- and time-related functions
*   prep for next class

*   Reading
    *   DB Reading packet 10 - Transaction Management - part 2
    *   SQL Reading Packet 8 - Simpke Reports, Parts 1 and 2

*   Should be working on Homework 10 - due 11:59 pm Friday, December 3rd
*   Should be working on Project POPULATION Milestone - due be 11:59 pm
    on Sunday, December 5th

-----
continuing Transaction Management - Part 2 ...
-----

*   resource locking is NOT the ONLY way to manage concurrent transactions
    on shared resources;

=====
Time Stamping algorithms
=====
*   when each transaction is started, it is assigned a global, unique,
    monotonic (time stamp values always INCREASE) time stamp;

    all the database operations of that transaction
    are considered to have its transaction's time stamp;

    *   The DBMS ensures that any *conflicting* operations (of transactions)
        are executed in TIME STAMP ORDER,
	thereby ensuing serializability

        if the DBMS determines that the actions of 2 transactions
	conflict, it STOPS one of them (the one that would violate
	time stamp ordering), roll it back, and restart it
	(thus it gets a new, bigger timestamp at that point

------
going into a LITTLE more detail...
-----
*   With each data "chunk" Q, you associate two time stamp values:
    *   W-timestamp(Q) - the LARGEST time stamp of a transaction
        that SUCCESSFULLY wrote Q

    *   R-timestamp(Q) - the LARGEST time stamp of a transaction
        that SUCCESSFULLY read Q

*   if Ti issues read(Q):
    *   if TS(Ti) < W-timestamp(Q),
        *   read(Q) will be REJECTED, and Ti will be rolled back
	    and restarted

    *   else (if TD(Ti) >= W-timestamp(Q)),
        *   read(Q) will be executed,
	    R-timestamp(Q) will be set max(R-timestamp(Q), TS(Ti))
                                       ^^^

*   if Ti issues write(Q):
    *   if TS(Ti) < R-timestamp(Q), then a "later" transaction has already
        read and used this value -- so it should not be written by Ti
        *   write(Q) will be REJECTED, and Ti will be rolled back
            and	restarted

    *   if TS(Ti) < W-timestamp(Q), then Ti is trying to write
        an obsolete value of Q
        *   write(Q) will be REJECTED, and Ti will be rolled back
            and	restarted

    *   else, write will be executed,
        and W-timestamp(Q) is updated to TS(Ti)

======
optimistic methods
======
*   suitable for scenarios where it is a reasonable assumption
    that the majority of database operations will not
    conflict!

    *   this approach: no locking, no time stamping --
    *   a transaction is executed without restrictions until it is to
        be committed --
	transaction moves through 3 phases:
	*   read phase: transaction reads the database, executed its
	    desired actions, but makes any updates to a PRIVATE copy
	    of the database values;

        *   validation phase: the transaction is validated to assure that
	    the changes made will not affect the daatbase's integrity or
	    consistency;
	    *   if validation test succeeeds transaction moves to the
	        write phase
		if it fails, transaction is restarted, and its
		changes discarded

        *   write phase: the changes are permanently applied to the
	    database