Hi,

A serviced component with transaction attribute Required connects to SQL
Server via an inline coded connection string and does some work in the
database. It also creates and calls another component with transaction
Required (so joins the current txn) that does work in the same or another
SQL instance.

Out of curiosity, how does COM+ know that all this belongs to ONE logical
transaction. What logic makes sure that the Open methods of ADO.NET (or
ADO?) of the components are communicated to COM+ so that it knows what
database connections are enlisted in the txn?

Thanx for any educational resonse ;-)

Hans

Hans,

You might want to avoid hardcoding your connection strings

COM+ knows it because the way your components are configured. Also, it knows
because when an instance of the components is created, COM+ knows about this
and then creates a special context in memory in which to run the objects
themselves, and it intercepts calls coming into and coming out of this
context.

When COM+ creates the transaction for the first component (which it knows to
do because the registration in the catalog tells it the component requires
it), it associates it with the context the object was created in. When the
object then creates an instance of the second component, COM+ notices that
the second component can run inside the same transaction as the first one,
and then configures the new context (to run the second object in) to point
to the same DTC transaction as the first one.

Finally, the reason why the ADO.NET connections maginally join this
transaction is because the ADO.NET providers that support distributed
transactions explicitily check when you request a connection if they are
being called from inside a COM+ context that is associated with a
transaction, and if so, join the connection to the transaction before
handing it back to your code for using it.

A book that explains this in heavy detail is Tim Ewald's Transactional COM+,
or Juval Löwy's "COM and .NET Component Services".
Here are some good articles on the topic, as well:

http://msdn.microsoft.com/msdnmag/issues/01/10/complus/
http://www.awprofessional.com/articles/article.asp?p=167771&rl=1
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/html/50ccf75e-2652-4254-a771-af83cc9248b3.asp


--
Tomas Restrepo
tomasr (AT) mvps (DOT) org
http://www.winterdom.com/

Of course! What I meant is that "only the component knows what SQL Server is
gonna be used"

That helps! But still sounds a bit like magic. Exactly when does COM+ peek
what SQL Server is gonna be used (and how), or perhaps the other way round,
when does the ADO.NET connection tell COM+?

Also thanx for the pointers, but haven't looked there for answers yet...

Hans

Hi Hans,

That last part is exactly what happens. The Data Access Providers are the
ones that know what server they need to open the connection to and interact
(alongside the database server) with the DTC to enroll the connection into
the distributed transaction.

In the case of, for example, SqlClient, exactly where this happens is fairly
underneath the covers, since the connection pooling support has to be aware
of this happening (a connection that was joined to a transaction cannot be
joined to another transaction until that one is done, so this changes the
basic criteria for handling out connections from the pool).

If you want to know exactly where this happens, check out the code for the
TryGetResourceFromContext() method of the
System.Data.SqlClient.ConnectionPool class, which basically uses the
System.EnterpriseServices.ContextUtil class to check for the COM+ context
and verify if it has a transaction associated with it.

Also, you might be interested in knowing that there are two other options
that control how this process happens:
- If you don't want your connections to join a DTC transaction available in
the COM+ context, you can simply especify "Enlist=false" as part of the
connection string
- You can also manually join a sql connection to a DTC transaction via the
EnlistDistributedTransaction() method of the SqlConnection class.


--
Tomas Restrepo
tomasr (AT) mvps (DOT) org
http://www.winterdom.com/

Lorenzo,

I cannot find any info about System.Data.SqlClient.ConnectionPool or
TryGetResourceFromContext in neither the 2003 nor 2005 documentation of
Visual Studio. The class seems not to exist, not even visible with
QuickStart's .NET Framework Class Browser which uses Reflection to peek into
the actual assemblies!?
Google has found one (as in 1) hit on TryGetResourceFromContext and "only"
10200 hits on System.Data.SqlClient.ConnectionPool. Seems to be not the
coolest identifiers for the majority of developers...

Cheers,
Hans


"Tomas Restrepo (MVP)" <tomasr (AT) mvps (DOT) org> wrote