One of the new matters: transactions in DOTNET and COM
Small gas god 2002-4-16
Article Type: In-Depth Difficult Level: 6/9 Version: 2.32
Isolation level
Read uncommitted
This is the smallest isolation level, which does not provide any transaction isolation, which is easy to cause dirty reading. This isolation level is very dangerous when multiple concurrent transactions in large applications, and this isolation level is not suitable for bank finance and other high-precision matters. The advantage is that no need to lock, so greatly reduce the service waiting time and improve system performance.
Read committed
This isolation level solves the problem of dirty reading, ensuring that the data written to the database but has not been submitted, that is, it guarantees that the read data is consistent and reads those submitted data. This isolation level cannot solve the problem of unreadable and phantom, but it is the default isolation level of MS SQL and Oracle. REPEATABLE READ
This isolation level solves the non-readable problem, ensuring that each of the data acquired from the database and the same amount of data, and then makes the application to the client, and then make the application to modify such applications, "After all, it is responsible for me Sites of this. The phantom problem is allowed in this mode, which is only locked in the data serializable that we want to update (responsible).
This isolation level is the stricter, solving three possible data inconsistencies. Ensure that each transaction is performed according to a certain sequence, completely isolated. Everyone is row, only a small number of unable conflict matters will handle parallelism (other allocation), in addition to paying data inventory, you can read and write almost.
Different isolation levels will cause the RM to generate different locks during the transaction to control the access data during this period, may always be retained to transaction commit or rollback. Root Objects will determine the isolation level of the entire transaction, which typically occurs when the transaction is just created, once the root object determines the transaction isolation level, then this isolation level will affect all objects in the entire transaction boundary and submit throughout the transaction Or keep the authority before rollback, the internal object after the root object can no longer require its own unique transaction isolation level or the level of conflict, COM can allow other internal objects less than or equal to this transaction isolation level, if The requirements are greater than this transaction isolation level, and Com will refuse to create this object in their own environment. For the Any options we have not included in the table, this object can be adapted or an arbitrary isolation level. For objects that set the Any property, COM wants to see if this object is a root object, if it is an object, then COM cautious care The default gives it a SERIALIZABLE isolation level, otherwise it can give it a quarantine level according to the isolation level in its transaction boundary or the Isolation level it accesses.
COM allows you to adjust and specify concurrent control (indirectly control database lock) in a higher level, how to control the right rather than too loose or too strict quarantine. But in any case, some controls have not allowed to control you more choices.
COM transaction service is currently some of the shortcomings
1. For some applications that do not need to distribute transactions, use COM look too much smaller use, significantly affect the performance of the program. For example, a single database application and simple and ordinary business application phone book management, personal information management, message book application, etc. Two-segment submits that spend greater COM more distributed transactions distributed over multiple databases distributed across multiple computers. 2. Do not require distributed deployment and calls, do not use local DTC, but require a complete and streamlined application of transaction characteristics. 3. Using COM function in DOTNET, it is inevitable to pay some Com Interop spending, of course, not a big problem, but almost all developers prefer "pure feelings" - CLR-Managed COM API 4. Com only supports the definition transaction attributes of the entire class, and does not support transaction attributes in a class. In the past time, we put different functions in a class (such as query, delete and update), resulting in a bottleneck in a class in a class (such as query, delete, and update), resulting in a bottleneck in each query function. And embarrassment. 5. COM The default is also the only transaction isolation level is serializable. Although the legend is a programmer, this problem has caused this problem, but some decision analysis and statistical applications are lost, and the range of error can be allowed Licensing They are forced to use the most stringent concurrent control, which means that they can only give up performance and ultra-precision data that is not very needed. Also even if the latest version of COM still does not support the above-described method-level transaction isolation definition, the idea of different isolation levels of different transaction attributes is defined for each method in a class, which is undoubtedly crazy. 6. The issue of "SEMI-Transactional Objects", and similar to the properties of the method level above. The latest information indicates that the new version of COM provides some solutions, Microsoft thinks them can only reduce and avoid such problems in COM 1.0. When will the transaction begin?
Understanding the start and end of the transaction allows us to examine the border of each participating object from a transaction border.
When is COM starting a transaction? In both cases, COM will automatically start a transaction: 1. When a non-transaction attribute is called a COM component that identifies the need or needs a new transaction 2. When a client, a client called a logo requirement The COM component of the new transaction When COM determines an object requires a new transaction, it will first start a transaction at the location of the current object, then it will be some operations below: 1. COM Create an environment (Context) object, set its JIT Activation and Synchronization attributes as needed, and set internal maintenance consistent and done flags. 2. COM Notification DTC will start a transaction, DTC configures a physical transaction 3. DTC generates a new transaction and returns the GUID ID that identifies this transaction to COM . The transaction ID will create a transaction environment boundary, and all objects participating in transactions will share this identity. COM saves this transaction to 4 in Context. When the client establishes this object, COM activates it in the environment of this transaction.
The first object in the border of the transaction is very special. It is the root object we generally said, and there is only one root object in a transaction. Other objects under the root object are called internal objects.
When is COM ending a transaction? In the three cases, COM will end a result of a transaction is submitted or rolling. 1. The execution of the transaction exceeds the deadline, then COM will automatically end the transaction that is not submitted during the timeout period, and all objects related to the transaction are no longer in the activation state, and the transaction rolls back. Generally, the default transaction timeout is 60 seconds. 2. The root object completes its work in a call, Com releases its reference (proxy and stub), and then the root object is no longer in the activation state, and the entire transaction starts to be submitted. 3. The root object is released by Client, the reference to the COM release object (the agent is not a regenstration, and the root object is no longer in the activation state, and the entire transaction begins to submit. COM submit or abandon affairs
For effective work, COM maintains two flags CONSISTENT and DONE in each environment (CONTEXT). These two flags affect the transaction whether it is submitted or gives up, and the developer rely on the two flags to tell COM to the view of the transaction, COM according to the state of these two flags, how to interact with RM. In fact, there is a truth that has been ignored: objects with transaction attributes do not participate in two two submission processes (that is to say without witnessing the results of the entire transaction), but all the processes RM and DTC have completed this process (return and Implementation, and announce the result). All objects in the entire transaction border are only voting for transactions. When all components agree, Com will tell these votes and tell DTC for the final result, you used to create a transaction for me (by guid The logo) can be submitted, and the DTC requests the RM of all the applications to submit their changes. At this time, all objects that have been involved in voting have been destroyed or to the object pool, in short, they are no longer in the activation state. That is to say, the root object is simply obtained after calling setcomplete returns (when the transaction starts and ends it at all), other objects have not known to the transaction result (just cast itself before dying One vote), two submission processes may fail. Then COM will change the return value of the S_OK obtained by the original root object (Context_e_aborted), and finally the only root object knows the final result of the transaction. Of course, if the root transaction calls setabort, then the result is a prior to know, but the root transaction is the same as that, it is still not in the active state. Simply put, the root object is released to force COM to enter its transaction vote. After the root object is released, COM will also release all objects in the transaction domain, so the temporary vote of all objects must be determined before the COM statistics vote (this is the last deadline), then COM knows is submitted or rolling, the transaction It is no longer allowed to allow any thread or object to enter (Isolation is the JIT activation requirements, and this isolation guarantee if the Isolated object can be brought into the next other transactions, and this isolation guarantee is Through the synchronous domain (another), the entire transaction has been safe until the end is safe).
How do developers control these two flags, especially if they realize the transaction mechanism, we must know this voting algorithm. The following list is listed in the way we use to modify these two signs:
Method or function can be used
CONSISTENT BIT
DONE BIT
IOBJECTCONTROL :: SetComplete
True
True
IOBJECTCONTROL :: setabort
False
True
IOBJECTCONTROL :: EnableCommit (Default)
True
False
IOBJECTCONTROL :: DisableCommit false false icontextState :: get / setMytransactionvote
According to the incoming parameter icontextState :: get / stateactivateonreturn
According to the incoming parameters
COM Use these two flags according to the following rules to collect vote: 1. Under COM will check when the current function returns, if the Done bit is true, then COM will make this object to be activated, otherwise False, COM continues to keep this object. 3. COM Check the value of the Done bit when the method call returns or when an object is lost, if true, COM pays attention to the value of the consistent bit, if the consistent bit is TRUE, then indicate that it is submitted, otherwise it indicates back roll. 4. COM only reads the transaction vote when the object is activated. If the object is not released to COM , then the vote is read after the last client releases it. That is, when the Done bit is TRUE, COM starts reading the CNSITENT flag. 5. Since all objects in the entire transaction boundary will share these two flags, each flag can set multiple times before the object is lost, and multiple changes can be set multiple times (the temporary vote "above"), COM Take the last change as a count. According to the rules above, we can make such simulations in the program to implement their own transaction mechanism:
By default (Class Construction) Submitted before the return, temporarily not submitted for the temporary ISHAPPY = true isdone = FALSE
Isdone = true ishappy = false isdone = true
Isdone = false
Isdone = true ishappy represents the consistent flag, isDone represents the Done flag, and then we can determine this:
CurrentTranscationContext.isdone)
{
CurrentTranscationContext.ishappy)
{// done == true && consistent == TRUE
CurrentTranscationContext.Commit ();
}
Else
{// done == true&& consistent == false
CurrentTranscationContext.rollback ();
}
CurrentTranscationContext = NULL;
}
At last
Above we examined the COM programming under the CLR, I have distinguished some fuzzy concepts, and the properties have also been used and convenient in transaction programming mode. One is affirmation: The entire COM model does not change because of the CLR, COM is still the original COM , trying to learn the DOTNET to avoid learning COM may give you back to the original place, in the future DOTNET development model and architecture In COM , it becomes the most basic technology and components. The new version of COM shows an improvement in the transaction model, such as setting a transaction isolation level, but it also has some obvious shortcomings and insufficient, we can see the use of DOTNET and CLR and more DOTNET environments. Services and how to improve and avoid these shortcomings, and even throw away COM to establish their own business environment and mechanisms, and on the other hand, some of the views of this article will be some views of the transactions, will be our own implementation mechanism and understanding affairs. The model must be necessary. especially:
This article 9CBS signature start, reprint, or adaptation, please indicate the author and the source. If there is a problem, please send an email to new2001@msn.com
The above text and pictures involve other people's privacy and personal rights, all texts and pictures are only used for internal communication and do not make any news published and commercial purposes.
