Attachment A: Profile
A transaction is a series of actions to perform as a single logical unit, which means that these movements are either successful, or all fail. If the last action fails, the previous action should roll back in a second, and the entire state returns to the state where the original transaction begins. For example, there are 1,000 US rounds to deduct from a bank account, transfer to another account, then the transaction guarantees that both events can only be successful, as long as there is a failure, then there will be no action, and the two accounts have not changed. Money is not deposited and deducted.
ACID attribute
There are four attributes that are often used to describe transactions: atomicity, consistency, isolation, durability. In an ideal environment, the transaction meets these four standards, but the isolation level of a transaction can be set, because the isolation level of a thing is to be the best "sequential" will increase by "sequential". " The chance of dead locks. The deadlock is two transactions trying to lock the resource that has been locked by the other party. The last business needs to roll back, so that another will continue. In order to avoid this situation, you require reduction of an isolation level of a transaction to reduce its battle.
l Atomicity: The business should work as an atomic unit, and it is necessary to implement success, or all failed.
l Consistency: You need to keep all data consistency after the end of the transaction. In a relational database, all rules should occur on the changes caused by transactions to maintain data consistency, all internal data structures, such as B-Tree Index, the bidirectional coupling must remain correct after the end of the transaction.
l Isolation: Changes made concurrent affairs must be isolated from any other concurrent transaction. A transaction either sees other transactions to change its previous data, or you can see the temporary data after seeing other transaction changes. . . . . .
l Persistent: After an end, its results will last forever, and its changes will exist even in the system.
Transaction support level
Support level
description
Isolated
Ignore the transaction environment
not support
Objects or pages are not running in a matter of matter. Requests come, no matter whether there is an activated transaction exists, the object's context is created as a non-transaction type.
stand by
Objects or page run in an existing transaction environment, if there is no transaction, it is not running in transaction.
need
Objects or page run in an existing transaction environment, if the environment is not transaction, you will create a new one.
Need new
Objects or pages require a transaction, each request will create a new transaction.
Table 2: Transaction support level
For ASP.NET, the default transaction level of the page is "isolated", the default level in the enterprise service "needs", in general, we will set the level as "need" on the first layer of the transaction, called "need", called The object is set to "Support". This means that the top-level object creates a transaction. When each called object is activated, it will enter the context of this transaction.
Transaction isolation level
In a program, there will be three situations based on the isolation level of the transaction.
l Dirty: A transaction will read data that has not been submitted by another transaction, so you will see some data that is finally rolled back by another transaction.
l The reading value cannot recover: a transaction reads a record, another transaction changed this record and submitted, when the first transaction read this record again, it has changed.
l Phantom Read: A transaction with a WHERE clause to retrieve a table's data, another transaction inserts a new record and complies with where conditions, so that the first transaction uses the same WHERE condition to retrieve the data, will be more A record. Support level
description
Reading uncommitted
The lowest isolation level, this level of transactions have dirty reading, read values do not referendum and phantom readings.
Read
Many database default levels, this level you may encounter read values without referendum and phantom read.
Repeatable
This level will encounter a phantom read.
Sequential
It is completely isolated between the transaction, in COM 1.0, this is the only option, but in COM 1.5, it is only one of the options.
Table 3: Transaction isolation level
The isolation level selected by a business affects how the database treats the locks owned by other transactions, and the isolation level you choose relies on your system and business logic. For example, a bank checks its account balance before the customer is checked, in which case an isolation level is a sequentially-sequential transaction, so that another money will not be executed before this time. If they only need to provide an account balance, "Read Submit" will be the right level, because they only need to query the value of the balance, and the level reduction will make the transaction faster.
Advantages of B transaction development
l Test the transaction controller under a certain load to ensure that the deadlock under load will not occur.
l Use stored procedures as possible, they still have the best performance in various situations.
l Enterprise-level services provide a high-level way for transaction control, but use it to be cautious because it reduces performance
l Analyze your system to decide which isolation level transaction. Banking system should use sequential isolation levels
Attached C monitoring
There is no special mechanism to track database transactions and ADO.NET transactions.
ASP.NET and enterprise-class transactions can be monitored by the console component service program, and the component service can be found in the management tool for the start menu. From this tool, you can monitor all transactions running through MS DTC, which is the ASP.NET and enterprise-level services. You can also monitor the execution time of your transaction, even transaction, roll back, and cancel the whole process.
With D dead lock
When two or more processes (or threads) have the lock required to each other, a deadlock occurs, typically in a database system, but may also occur in any multi-threaded program, such as:
Transaction 1
Transaction 2
Lock table A
Lock table B
Update Table A
Update Table B
Try to lock table B
Try to lock table A
At this moment, both transactions cannot continue because they all try to lock the resources that the other party has locked, and the two transactions cannot know the state of the other party according to the rules of the transaction. SQL Server detects this happening, selecting one of the rollbacks, which at least one transaction can be done normally. At this moment, the program that controls which transaction is sacrificed has to be decided to reboot this transaction or throw an error to the user. Generally, SQL Server will sacrifice the transaction started after that, or to unlock the transaction of the most deadlock.
One of the deadlocks is that the database will automatically make a rollback, which will cause a problem in the rollback code of the intermediate layer, if you encounter a deadlock, and can intercept an abnormality in the middle layer, when the middle layer is back When you are rolling, you will get another exception, so you have a second exception, because SQL Server has already made a rollback for you, so you are actually the second time, then SQL Server Can't find a rollback. So a good habit is to put the rollback code in a try catch, or match this exception to SQLException, and detect the SQLEXCEPTION exception code, if it is 1205, then the situation of deadlocks occur. E.g:
Try
{
// Run SQL Commands in ado.net transaction
Catch (SQLEXCEPTION SQLEX)
{
// Specific catch for deadlock
IF (sqlex.number! = 1205)
{
TX.rollback ();
}
ORDERID = 0;
Throw (SQLEX);
}
Avoid the method of deadlock
There are several ways to reduce the chance of deadlocks in the transaction.
l Trying to access the table in the same order in the transaction, in the previous example, if the two transactions access table B after the two transactions, then avoid dead locks, both transactions can succeed.
l Avoiding users in transactions / tried to be small in transactions, long running time, increase the chance of deadlocks that have occurred and other transactions, running transactions during stored procedures, may use the shortest time.
l With a low isolation level, set the isolation level of your transaction to minimize the risk of reducing your business, default, SQL Server sets the isolation level to "read submit", this means If a transaction locks some data in order to read, another transaction allows lock it to read, write, delete, and changes, which will generate "phantom read", but is acceptable in the general business.
l Using Bound Connections, under this condition, two connections share a transaction / lock space, thereby avoiding lock conflicts.
