*   yes you can concatenate to a sequence in an insert statement...

drop sequence widg_seq;

create sequence widg_seq
increment by 1
start with 1000;

insert into widget
values
('B' || widg_seq.nextval, ...);

*   transaction management and concurrency control

    *   intro a few more-advanced database topics...
    *   many of these could be an entire course in themselves...

    *   collection of concepts related to
        transactions and concurrency

*   transaction - *LOGICAL* *UNIT* of work
    *   discrete! not divisible!

    *   it may actually take many steps "under the hood" to
        accomplish,

	but we'd actually like it to be as if it were ATOMIC,
	indivisible; 

	...and thus we want a chunk of work
	   that is being considered to be a transaction
	   to be COMPLETELY done,
	   or COMPLETELY not done (as IF it had never even been
	       started)

        *   yes, we CAN use SQL commit and rollback to help
	    achieve this;

   *   transaction - also known as an atomic transaction or logical unit of work (LUW)
       is a series of actions representing a single logical unit of work
       taken on a database such that
       either ALL of that transaction's database actions are done
           successfully,
       or NONE of them are and the database remains unchanged

       *   defining a series of steps as such a logical transaction
           is an important "piece" within the area of concurrency
	   control,

	   because we'd like this behavior even when pieces of different
	   transactions are being done at the same time;

*   consistency comes into play here, also
    *   a consistent database state is one in which all database
        integrity constraints are satisfied

    *   we'd like a transaction to alter the database from
        one consistent state to another consistent state

        ^ transactions need to controlled and executed by the
	  DBMS (with the assistance of the application program(s))
	  to seek to guarantee this;

    *   remember our discussons of different levels of database integrity?
        *   entity integrity - if the DBMS requires unique, non-null
	    primary keys, it is supporting entity integrity;

        *   domain integrity - if the DBMS supports restrictions on
            an attribute's domain -- and won't allow a column's value
	    to be a value outside of the given domain (on at least a
	    physical domain level)

        *   referential integrity - if the DBMS supports foreign keys
	    
        *   transaction integrity - if the DBMS supports atomicity
            of transactions, it is supporting this
	    (a transaction's impact on the database is as if it
	    were completely done, or as if it had never been started)

*   note that SQL's 	    
    commit;
    rollback;

    are ONE (not the only) such means to help with transaction
    integrity;

    *   commit - expected to permanently record all changes to the
        database since the previous commit 

    *   rollback - expected to "roll" the database "back" to its
        previous consistent state, to its state at the time of
	the latest commit

    *   note that many DBMSs provide for various autocommits --
        e.g., when you change the database structure,
        and when you exit sqlplus, for example

*   NOTE the following important/desired database transaction
    properties:
    (we'll be discussing these further on Tuesday)
    *   ACIDS
    *   Atomicity
    *   Consistency
    *   Isolation
    *   Durability
    *   Serializability