Using transactions to protect the integrity of data in Ado.net (2)

ado| Data Transaction Analysis

A transaction consists of a minimum of two steps – start, then commit or rollback. The start call defines the bounds of the transaction, while the call commits or rolls back at the end of the definition. Within the transaction boundary, all execution descriptions are considered to be part of the complete task and must be a success or failure. If all is submitted successfully, all data modifications will be performed, and if any errors occur, the rollback will cancel the modification. All. Net data provider objects provide similar classes and methods to accomplish these operations.

Isolation level

An orphaned hierarchy defines transaction isolation behavior in a transaction. The higher the isolation level, the less the data will be disturbed by other transactions. Many databases increase isolation levels by locking them. You should perform two times to check your target DBMS for use. Good practice is to compromise on performance and concurrency, and more lock systems will have to be maintained, the more the words are prone to conflict and the lower the speed for different processing.

The following list is the isolation level support for ado.net from the. Net Framewok SDK. The following list of isolation hierarchies is becoming more restrictive.



Member name
Description
Value

Unspecified

Supported by the. NET Compact Framework.
A different isolation level than the one specified are being used, but the level cannot to be determined.
-1

Chaos

Supported by the. NET Compact Framework.
The pending changes from the highly isolated transactions cannot is overwritten.
16

ReadUncommitted

Supported by the. NET Compact Framework.
A dirty Read is possible, meaning that no shared locks are issued and no exclusive locks. are honored.
256

ReadCommitted

Supported by the. NET Compact Framework.
Shared locks are held while the "data is" being read to avoid dirty reads, but the data can being changed before the end of the Transaction, resulting in non-repeatable reads or phantom data.
4096

RepeatableRead

Supported by the. NET Compact Framework.
Locks are placed on "all data" is used in a query, preventing the "other users" from updating the data. Prevents non-repeatable reads but phantom rows are still.
65536

Serializable

Supported by the. NET Compact Framework.
A Range Lock is placed on the data set and preventing other users from updating or inserting rows into the dataset until the Transaction is complete.
1048576



Note: The unordered isolation level is not supported by SQL Server or Oracle, only the OLE DB data provider object will accept it as an orphaned level set transaction. If you attempt to set it with SQL Server or Oracle, you will get a ArgumentException that indicates an invalid isolation level parameter.

SQL Server and Oracle and OLE DB data provider objects default to the ReadCommitted isolation level.　ODBC data provider objects have different default isolation levels, depending on the ODBC driver.　If you consider that readcommitted is not the isolation level you want, you can use the Transaction.isolationlevel attribute to specify different levels.　You should be very careful about modifying these settings, although the appropriate tests are performed to ensure that these changes do not affect data consistency or other concurrency problems. If you have a database administrator, you should ask them about the appropriate level of specific tasks. You should also check the database documentation to see how your database handles orphaned hierarchies and locks.

Local rollback

Normally, if a transaction happens incorrectly, you will find that the place you want to roll back is not the whole transaction.　You want to do this only when you are fully successful in dealing with a transaction that requires a lot of time.　But checking the success of the partial execution will be expensive. You have to balance the cost of data modification and have to roll back some small parts to avoid spending too much.

Partial rollbacks typically use savepoints or inline transactions, depending primarily on how your database works. Some DBMS do not provide this mechanism, so check your database documentation to see if or how to implement a local rollback.

SQL Server and Oracle allow the use of savepoints (which you can reference when causing a rollback) to stop rolling back at a predetermined point.　They don't really do inline transactions, and some other DBMSs to do the same work. SQL Server allows you to use embedded transactions in the simplest sense, you can use the embedded start ... Commit T-SQL block statements. However, only if all transactions are actually committed outside of the commit, the system variables are consumed within the submission process, so you can track how many transactions you have open.

Some databases perform real inline transactions. For these data types, the inline commit will actually commit the responding transaction, even if the external transaction rolls back the embedded transaction.