DCOM vs MTS/COM+

[CW2002]

It doesn't look like there are any gurus in this forum. But there is no harm in asking.

If I implement transactions (including distributed transactions) entirely on
SQL Server, instead of relying on MTS/COM+ , and I mark my DCOM components
as thread per object, is there any performance gain or scalability gain from
migrating components from DCOM architecture to MTS/COM+ architecture?

I must admit that I haven't yet come across a case where SQL Server
transaction could not do a job as well as MTS/COM+, but I'd love to hear
some scenarios where I must use MTS/COM+ instead of SQL Server.

I know that MTS/COM+ components created in VB can't take advantage of object
pooling, and it has to share STA pools if clients exceed 100 (which means it
is possible for a call from one client to block other clients sharing the
same thread). I can't see any advantage of migrating my code from DCOM to
MTS/COM+.

Or am I wrong here? Is there any other performance/scalability issues that
make MTS/COM+ more attractive to DCOM architecture, despite that I don't
need transaction capability of MTS/COM+?

I'd love to hear some ideas here

Thanks in advance

 

[danceman]

Well you said a mouth full. I am not a diehard of any method. I do believe though you need to keep in mind:

1. life expectance of app
2. future growth
3. portability, is it needed?

MTS transaction procesing fit the need without changing any code if your data source changes.

well I said a mouth full, or just enough to make matters worse. Attitude is Everything

 

[CW2002]

>>MTS transaction procesing fit the need without changing any code if your data source changes.<<

The same applies to DCOM as well though. When underlying data sources change, you change the stored procs that the Data tier calls. It's the same in DCOM as well as MTS. I don't see any difference between the two approaches here.