trasactionAtributte Vs SqlTransaction object

K

Ken

This is a basic question:

Is it better to use the TrasactionAtributte on a Web Method (COM+) than use
a normal SqlTransaction object ?

What is the advantage on performance and transaction security?

ken
 
D

Dan Rogers

Hi Ken,

Here's my take on your question.

When you choose to use a SQL transaction, you are defining the boundary of
the transaction in your stored procedure or application code. This will
work fine for many self contained applications that are not intended to be
aggregated into larger transactions in a compose-able manner.

When you use COM+ transaction attributes, you are describing how your
component can participate in a transaction. For instance, you can say that
your component will not participate in a transaction, that your component
always opens a new transaction context, or even that your component can
participate in an existing transaction - starting a new one only if one is
not already started.

This kind of declarative and compose-able transaction ability lets you
program components that can be placed into transactions in ways that the
original programmer didn't know of at the time a component was coded.

Contrast this to the self contained, and non-compose-able SQL transaction
object, and you end up with several useful transaction approaches to use as
you need them in your application designs.

As for efficiency, that is a hard to pin-down term without more specifics.
There is programmer efficiency, network efficiency, throughput factors,
etc. That said, it is fair to say that some people feel that COM+
transactions and the use of the distributed transaction coordinator
introduces added scale-out issues to consider before making a statement
that places one transaction approach over the other with an "always"
attached. In the SQL transaction, the one SQL server is the arbibitrator
of the transaction bounds, so there is less communication going on over the
network. However, in the case where you need to coordinate
two-phase-commit over several resources that are transaction enabled, you
end up using a coordinator anyhow, so the only gain is in the
single-database, database-only, multi-table consistent update case.

I hope this helps,

Dan Rogers
Microsoft Corporation
--------------------
 
K

Ken

uff helps a lot, Thks.

Dan Rogers said:
Hi Ken,

Here's my take on your question.

When you choose to use a SQL transaction, you are defining the boundary of
the transaction in your stored procedure or application code. This will
work fine for many self contained applications that are not intended to be
aggregated into larger transactions in a compose-able manner.

When you use COM+ transaction attributes, you are describing how your
component can participate in a transaction. For instance, you can say that
your component will not participate in a transaction, that your component
always opens a new transaction context, or even that your component can
participate in an existing transaction - starting a new one only if one is
not already started.

This kind of declarative and compose-able transaction ability lets you
program components that can be placed into transactions in ways that the
original programmer didn't know of at the time a component was coded.

Contrast this to the self contained, and non-compose-able SQL transaction
object, and you end up with several useful transaction approaches to use as
you need them in your application designs.

As for efficiency, that is a hard to pin-down term without more specifics.
There is programmer efficiency, network efficiency, throughput factors,
etc. That said, it is fair to say that some people feel that COM+
transactions and the use of the distributed transaction coordinator
introduces added scale-out issues to consider before making a statement
that places one transaction approach over the other with an "always"
attached. In the SQL transaction, the one SQL server is the arbibitrator
of the transaction bounds, so there is less communication going on over the
network. However, in the case where you need to coordinate
two-phase-commit over several resources that are transaction enabled, you
end up using a coordinator anyhow, so the only gain is in the
single-database, database-only, multi-table consistent update case.

I hope this helps,

Dan Rogers
Microsoft Corporation
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top