ADO.Net, Transactions, and ASP.Net

[Mythran]

I just want to know the advantages vs disadvantages of using Component
Services to handle our web application transactions over creating and
passing around a transaction object of our own? When would you use one over
the other, or use one instead of the other?

Thanks

Mythran

 

[Marina]

Advantages of COM+
Can have a distributed transaction over more then one database
Don't need to pass around the connection/transaction

Disadvantages of COM+
Have to have strong named assemblies - not optional
Can't use any non-strong named assemblies in your project
Easy wind up with some sort of configuration/versioning problem

Personally, I would avoid COM+ whenever possible. It is not that much effort
to have a central place to store your transaction related objects, so all
your code can use it. It really comes down to how many databases are
involved. If just 1, I would go for just ADO transaction, if more then 1,
you have no choice but to go with COM+

 

[Sahil Malik [MVP]]

Mythran,

COM+ based transactions, I presume enterprise services - are very expensive.
Plus atleast for enterpriseservices, they will need strong naming (unless
you can restrict yourself to serviceconfig). WHich makes them a pain to
deploy even.

The preferences is to keep it as close to the db as possible, so for a
single database, SqlTransaction still takes the cake.

- Sahil Malik [MVP]
http://codebetter.com/blogs/sahil.malik/

 

[Val Mazur \(MVP\)]

Just an addition. COM+ could be very expensive from the performance point of
view

--
Val Mazur
Microsoft MVP

http://xport.mvps.org

 

[Mythran]

Advantages of COM+
Can have a distributed transaction over more then one database
Don't need to pass around the connection/transaction

Disadvantages of COM+
Have to have strong named assemblies - not optional
Can't use any non-strong named assemblies in your project
Easy wind up with some sort of configuration/versioning problem

Personally, I would avoid COM+ whenever possible. It is not that much
effort to have a central place to store your transaction related objects,
so all your code can use it. It really comes down to how many databases
are involved. If just 1, I would go for just ADO transaction, if more then
1, you have no choice but to go with COM+

You would avoid COM+ because you have to have strong named assemblies? Not
a problem, all my assemblies are given a strong-name anyways. All our data
access and business logic components are registered in Component Services
and I only posted this thread because I wanted to know if it would be better
to go with something else. It seems that I would have to do a LOT of
passing of objects around to achieve what we already do with COM+. Not only
that, we do not see a performance hit with COM+ that everyone always seems
to mention when I ask questions about it. It has been pretty smooth thus
far. Anywho, thanks for the replies y'all.

Mythran