Hi Mark,

Thanks for posting in the community!
From your description, you seem to feel something unclear with the concept
of "Transaction management is centralized to the business process component
and does not need to be controlled explicitly by the Data Access Logic
Component" which is mentioned in the book <Designing Data Tier Components
and Passing Data Through Tiers>, and you are asking about the definite
meaning of the "Higher-level business process component", yes?
If there is anything I misunderstood, please feel free to let me know.

As for the above questions, here is my understandings:
1. The High-Level component means the Business process component , not the
Data Logic Access Component. The DLAC is the low level components to call
the row data access apis which finish some certain data manipulations such
as Insert, update,delete, select and the DLAC components are stateless
which won't contain any stateful infos or context. For example, such code
as
Open connection,  execute sql statement are all in the DLAC components.

However, the High-Level component(Business Logic process component)
commonly provide the application business logic dependent operations and
some of them are stateful. For example, query the orders for a certain
user, or create a order for a certain user.

2. As for the following description:
-------------------
Transaction management is centralized to the business process component and
does not need to be controlled explicitly by the Data Access Logic
Component. If you access multiple data sources from one Data Access Logic
Component, you will need the Data Access Logic Component to be the root of
transactions, which will introduce additional overhead on functions where
you are only reading data.
--------------------
I think the "Transaction management" doesn't means the trancation in any
Data Access API or database server such as the
--------------------
using (SqlConnection conn = new SqlConnection(connectionString))
{
 conn.Open();
 using (SqlTransaction trans = conn.BeginTransaction())
----------------------
you've mentioned. The "Transaction management" here means some business
logic based database processing control or organization. And the "multiple
data sources" may means different database, or even different database in
different database servers. In such cases, if we provide separate DLAC
components for the different datasources, we can put those certain "high
level transaction management" in the higher business component rather than
in the DLAC components. For example, we have order datas and product datas.
Both the two 's datas are distributed in two different database servers. I
named one is server "Local", another is "Remote". Now in two cases:
1). I provide separate order DLACs and product DLACs for the different
datasource(Local and remote) which means I need 4 DLACs, they are
DLAC_order_local,DLAC_order_remote, DLAC_product_local, DLAC_product_remote.
Then when I need to retrieve orders or products info from a certain server,
we need to provide determination for which DLAC to use, the determination
operation can be centralized to the business process component which uses
the order and product's DLAC components, just like:
if ( local needed)
{
call DLAC_order_local
call DLAC_order_remote
...// other DLAC for local
}
else
{
call DLAC_product_local
call DLAC_product_remote
...// other DLAC for remote
}

But in the DLAC, since one DLAC is only one datasource concerned, not such
determination operations needed.

2) If I provide a single DLAC component for both remote or local datasource
based order data accessing or product data accessing. I have to put the
logic determination into the DLAC compoenents. For example , in Business
logic component we use :

if ( local needed)
{
call DLAC_order_mixed( local param)
call DLAC_order_mixed( local param)

...// other DLAC for mixed
}
else
{
call DLAC_order_mixed( remote param)
call DLAC_order_mixed( remote param)

...// other DLAC for mixed
}

In each DLAC, we need to provide the datasource select determination such
as:
if ( local param pass in)
{
create local connection
...
}
else
{
create remote connection
....
}

Then, if we add more DLAC components such as employee, customer....  The
overhead of such "Business Transaction management" will increase as well.
Do you think so?

Please check out the above suggestions. If you have any questions or have
any different opinions on it, please feel free to post here. I'll be
willing to discuss it with you.

Regards,

Steven Cheng
Microsoft Online Support

George,
    Have you tried looking at enterprise services in .net. I think
thats much easier to manage and control using attributes than phsyically
creating transactions adn commiting and rolling back. If you need help
with that let me know
Thanks