--- Csaba Gero <[EMAIL PROTECTED]> wrote: > IMO the point is, if you are creating a "generic" component (whatever > this may mean :)), you cannot know the environment in which it may run > later and if it will have to run it in the same transaction with some > other components or not. In this case you currently have no other choice > than to go with COM+/DTC.
I think assuming it will work *with* COM+ in a "generic component" is equally difficult to prove. I recently inherited an application that used COM+ heavily, both for process isolation and for transactions. First, it turned out that the use of "requires transaction" and "uses transaction" had been misunderstood. But then, almost worse, making more liberal use of requires transaction pretty much caused the entire system to grind to a halt because of locking, deadlocks and my personal favorite, catastrophic failures in SQL server. Most of these problems had to do with the very conservative choices COM+ has to make in regard to locking. This was made worse by the fact that there are some fairly long running transactions. A seller of a generic component has no control over how the control will be used, or how large a transaction it will be involved in. COM+ doesn't give you much in the way of help here either. In our case we had to rewrite the context setup for each transaction ourselves and manage locking isolation levels in our stored procedures. At one session at Teched this year, the speaker suggested the the overhead for the DTC is 30-40%. Just getting that much time back by managing the transactions ourselves would have greatily reduced our deadlock issues. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.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.
