TransactionInteractionExplorer
=====================

This app explores the ability of a command to read data from a particular database table when that data is involved in a pending transaction on another connection.  The app permits a selection of different IsolationLevel settings for the transaction so the effect of each can be examined.

Suggested Experiments

Four experiments based on the TransactionInteractionExplorer are detailed below. The experiments listed explore the behavior of two operations, each conducted within the jurisdiction of a separate transaction, that access records in the same table.  Note that the TransactionInteractionExplorer permits you to conduct operation outside of transactions; but that option is not exercised within the experiments listed.  Rather, it is simply included to increase the flexibility of what you can test with the app as you design your own experiments.

Experiment No. 1 demonstrates that if the operation in transaction #1 is a read, then read operations in transaction #2 will be successful regardless of the isolation levels of either transaction. 

Experiment No. 2 demonstrates that if the operation in transaction #1 is a write, then read operations in transaction #2 will be successful only when the isolation level of transaction #2 is ReadUncommitted

Experiment No. 3 demonstrates that if the operation in transaction #1 is a read, then edits and deletes in transaction #2 will be successful only when the isolation level of transaction #1 is either ReadUncommitted or ReadUncommitted.  Edits and deletes in transaction #2 will fail when the isolation level of transaction #1 is ReadRepeatable or Serializable.

Experiment No. 4 demonstrates that if the operation in transaction #1 is a read, then adds in transaction #2 will be successful for all transaction #1 isolation levels except Serializable.

It is suggested that you run the experiments listed below in sequence, examining, as desired, the code that each experiment exercises.

General notes on working with the TransactionInteractionExplorer:

1.	Before any write (Edit, Add, or Delete) operation, you should first execute a Read Records operation to fill out the DataSet (and derivatively, the DataGrid).

2.	After each Rollback or Commit, the selected operation is reset to Read Records in order to prevent you from accidentally updating records in the Products table of the Northwind database when you dont intend to.

Experiment No. 1
------------------
This experiment demonstrates that if the operation in transaction #1 is a read, then read operations in transaction #2 will be successful regardless of the isolation levels of either transaction.

Process #1 Settings
- - - - - - - - - - - - -
Select Operation to Perform on the Local DataSet: Read Records
Select Operating Conditions
	Perform the indicated operation inside a Transaction
	Communicate DataSet updates to back-end database
Select IsolationLevel for Transaction: (any)

Process #2 Settings
- - - - - - - - - - - - -
Select Operation to Perform on the Local DataSet: Read Records
Select Operating Conditions
	Perform the indicated operation inside a Transaction
	Communicate DataSet updates to back-end database
Select IsolationLevel for Transaction: (any)

Expected Result of Experiment No. 1
- - - - - - - - - - - - - - - - - - - - - - - - - -
The read operation in process #2 succeeds.


Experiment No.2
------------------
This experiment demonstrates that if the operation in transaction #1 is a write, then read operations in transaction #2 will be successful only when the isolation level of transaction #2 is ReadUncommitted.

Process #1 Settings
- - - - - - - - - - - - -
Select Operation to Perform on the Local DataSet: Edit Current Record
Select Operating Conditions
	Perform the indicated operation inside a Transaction
	Communicate DataSet updates to back-end database
Select IsolationLevel for Transaction: (any)

Process #2 Settings
- - - - - - - - - - - - -
Select Operation to Perform on the Local DataSet: Read Records
Select Operating Conditions
	Perform the indicated operation inside a Transaction
	Communicate DataSet updates to back-end database
Select IsolationLevel for Transaction:
	First try ReadCommitted; 
Then try the read operation again with any of the other IsolationLevel settings: ReadUncommitted, RepeatableRead, or Serializable.

Expected Result of Experiment No. 2
- - - - - - - - - - - - - - - - - - - - - - - - - -
Only the read operation performed with an isolation level of ReadUncommitted will succeed.


Experiment No.3
------------------
This experiment demonstrates that if the operation in transaction #1 is a read, then edits and deletes in transaction #2 will be successful only when the isolation level of transaction #1 is either ReadUncommitted or ReadUncommitted.  Edits and deletes in transaction #2 will fail when the isolation level of transaction #1 is ReadRepeatable or Serializable.

Process #1 Settings
- - - - - - - - - - - - -
Select Operation to Perform on the Local DataSet: Read Records
Select Operating Conditions
	Perform the indicated operation inside a Transaction
	Communicate DataSet updates to back-end database
Select IsolationLevel for Transaction: 
To see success: select ReadCommitted or ReadUncommitted
To see failure: select ReadRepeatable or Serialized

Process #2 Settings
- - - - - - - - - - - - -
Select Operation to Perform on the Local DataSet: Edit Current Record or Delete Current Record
Select Operating Conditions
	Perform the indicated operation inside a Transaction
	Communicate DataSet updates to back-end database
Select IsolationLevel for Transaction: (any)

Expected Result of Experiment No. 3
- - - - - - - - - - - - - - - - - - - - - - - - - -
When the read operation in process #1 is performed with an isolation level of ReadCommitted or ReadUncommitted, the edit or delete in process #2 will succeed. When the read operation in process #1 is performed with an isolation level of ReadRepeatable or Serializable, the edit or delete in process #2 will fail.


Experiment No.4
------------------
This experiment demonstrates that if the operation in transaction #1 is a read, then adds in transaction #2 will be successful for all transaction #1 isolation levels except Serializable.

Process #1 Settings
- - - - - - - - - - - - -
Select Operation to Perform on the Local DataSet: Read Records
Select Operating Conditions
	Perform the indicated operation inside a Transaction
	Communicate DataSet updates to back-end database
Select IsolationLevel for Transaction: 
To see success: select ReadCommitted, ReadUncommitted, or ReadRepeatable
To see failure: select Serializable

Process #2 Settings
- - - - - - - - - - - - -
Select Operation to Perform on the Local DataSet: Add Record
Select Operating Conditions
	Perform the indicated operation inside a Transaction
	Communicate DataSet updates to back-end database
Select IsolationLevel for Transaction: (any)

Expected Result of Experiment No. 4
- - - - - - - - - - - - - - - - - - - - - - - - - -
When the read operation in process #1 is performed with an isolation level of Serializable, the add in process #2 will fail. When the read operation in process #1 is performed with an isolation level of anything besides Serializable, the edit or delete in process #2 will succeed.


Additional Experiments

You may wish to design your own transaction experiments using the TransactionInteractionExplorer. You can, for example, try some experiments where no transaction is wrapped around one or both of the processes.  Or, you may want to increase the command timeout used on the various commands so you have more time to terminate the first transaction before it causes the operation in the second process to time out.  The command timeout is controlled in the program by the constant kCommandTimeout which is declared near the top of the class module in the following statement:

    Const kCommandTimeout As Int32 = 2

The app also gives you the ability to explore the effect of an in-progress transaction in process #1 on an operation in process #2 that never updates the back-end database.  This, for example, permits an edit to show up in the process #2 DataGrid even though a Serializable transaction is in progress in process #1.
