A Couple of Big Caveats
A Couple of Big Caveats Before I dive into the subject matter of this chapter, I would be remiss if I didn't start with a couple of big caveats. First of all, the current implementation of .NET Enterprise Services appears to be just a stop gap. It may change significantly when Microsoft implements Enterprise Services on an entirely managed-code foundation. I think it is significant that, even though Microsoft has released a significantly improved version of COM+ with Windows XP (version 1.5 of COM+ ships with Windows XP), it has hardly promoted it at all. In fact, few people that I have talked to even know that there is a new version of COM+ in Windows XP. To me this is a strong indication that Microsoft is probably moving in a different direction sometime in the near future. Note See my article in the September 2000 edition of Visual C++ Developers Journal to learn about the new features that were implemented in version 1.5 of COM+, which shipped with Windows XP Professional and Windows .NET Server. Second, think long and hard before you decide to use the .NET Enterprise Services. The current implementation uses a great deal of unmanaged code. As you learned in Chapter 6, there is a significant performance penalty to be paid when you cross the managed to unmanaged code boundary. Microsoft has worked hard to minimize this penalty for serviced components , but there is still a price to pay in terms of performance. In reality, this admonition was true even before .NET came along. COM+ has always had a significant amount of overhead associated with its use. The interception architecture that COM+ uses means that making method calls between objects in a COM+ application can be slow. Moreover, people often use the distributed transaction support in COM+ when they really don't need to. If your COM+ business objects access a single database, you don't need the Distributed Transaction Coordinator (DTC) transactions that COM+ provides. Distributed transactions are only required if you need to create a transaction that involves multiple resource managers, for example, two databases or a database and a message queue, and you want the operations to be done in an all or nothing manner. This means that both databases are updated or neither is updated, or a database is updated and a message is written to a message queue, or neither operation is performed. Unless you need this kind of functionality, using the transaction service in COM+/.NET Enterprise Services is overkill. You are better off using the Transaction class from your managed provider ( sqlTransaction for the SQL Server Managed Provider and OleDbTransaction for the OLEDB Managed Provider) to create and commit your transactions manually. Note There is an excellent white paper in the MSDN Library called "Performance Comparison: Transaction Control" by Priya Dhawan, which provides an in-depth performance comparison of DTC and manual transactions.  |
| | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 119