Distributed Transactions: Intermittent problem reading data

microsoft.public.dotnet.framework.adonet

21 Apr 2006 1:36 PM

Anderw Miller

(this message is cross-posted to microsoft.public.mts.programming and
microsoft.public.platformsdk.complus_mts)

Summary of Problem:
Intermittently, a single threaded application reads data immediately after
it has been written in a COM+ transaction and the updated data is not seen.
The data is viewable in the database and a 2nd attempt to read the data
succeeds.

Details:
I have a .NET 1.1 application running on W2K that talks to a single Oracle
database using either MSDAORA or OraOleDb providers (never both at the same
time and the problem is seem much more frequently with MSDAORA) through
ADO.NET. The application uses MTS (COM+ C# ServicedComponents) for all
database updates and performs reads without a transaction using ADO.NET
directly. New (pooled) connections are pulled from ADO.NET for each call to
the database and are enlisted in the same transaction through the DTC.

We have a single thread that writes a change to a data value using the
transactional ServicedComponent and then immediately reads the updated value
from the database. Intermittely (and not easily reproducable or
identifiable) the call to read will fail to return the updated data (will
return the old data). If we add in a sleep(0) and read again we receive the
updated value.

This seems to indicate that the commit process is happening asynchronously,
however my understanding of the MSDTC is that with the configuration I
outlined above, the 2-phase commit process does not occur and the act of
leaving the root COM+ transaction context should perform a blocking call to
ITransaction.Commit that returns only after the data has been made durable.

Can someone confirm whether leaving the COM+ transaction context
synchronously performs a commit through the DTC? If so, are there any known
issues related to this (have searched both Oracle and MS managed groups)?

Thanks-
Andrew