Let me explain my philosophy a little more in detai :-) EVERY component should be ABLE to work toegether with a DTC - now, this is not so much about "distributed" transactions, but about transactions spanning multiple components - often on the same computer. Things like integrating an accounting system with transaction orders fed in by MSMQ suddenly requires COM+.
You need to be VERY careful with how you operate on distributed systems. One approach I facour is the combination of COM+ and .NET - basically a COM+ middle layer that is proxied on the client, and then the proxy loads business dll's from the COM+ server which are executed locally. This means you have oo on the client, but NO oo-property-get/set communication to the server. The client has it's own local COM+ application that is part of the remote application and has a CRM that is then dumping all necessary actions into the usiness layer on the prepare commit phase. Oh, ok - this is part of an O/R layer pretty often. For scalability get rid of OO - you need to think document centric. Send a "order document" down to the business layer and get a result document, maybe both as serialized com objects. But no "get/set calls and as few round trips as possible. For example, we currently implement an accounting system. Account Management is done by "normal function calls" - these are not often happening, and not transaction intagratable. Transaction entry is done by constructing a NewTransaction com obiect containing NewTransactionDetail entries. These are then sent over in a "EnterTransaction" call which executes a lot of database SP calls (actually in a batch). As a return, a number of Account records are returned containing new account values, which the business logic layer then uses to update a cache :-) If you ask the BLL about a current account value, you can specify you want a cached or a native value, which you normally do not want and which hits the database - cached queries do not hit the database. For the sake of integrity, this is done in a distributed transaction - actually in this particular case, transaction orders ARE read from MSMQ :-) NewTransaction objects can be serialized native or through the XMLSerializer, so you can use them in WebServices. When you want to integrate transaction semantics over web services, everything is there to help you - if you manage to couple your own tx semantics onto the COM+ transaction. If you need to use this subsystem in combination with another tx, then you are perfectly ok to do so - we integrate. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -----Original Message----- From: Craig Andera [mailto:[EMAIL PROTECTED]] Sent: Donnerstag, 16. Mai 2002 00:57 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier > I don't think spanning a transaction across multiple method > calls on the business tier is a problem as long as all those > alls are wrapped in a single call to the business tier that > starts and commits the transaction. Given that your database and your business tier machines are almost never one and the same, in fact having multiple method calls on the business tier can result in locks being held for dozens if not hundreds if not thousands of times longer than if all the transactional logic is contained in a single method/stored procedure. Long locks=bad scalability. And the real killer is that there's no way to cure it by adding more hardware. Database locking is the bottleneck to scaling in most systems, and it is best avoided by proper design. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
