Module 9: The Transactional Data Access Layer

Contents
Overview 1
Introduction to Transactional DAL 2
Technologies 5
Logical Design of Transactional DAL 12
Physical Design of Transactional DAL 13
Market Purchasing 18
Best Practices 21
Lab 9: Transactional DAL 22
Review 30

Module 9: The
Transactional Data
Access Layer

Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual

property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, ActiveX, BackOffice, BizTalk, FrontPage, Microsoft Press, MSDN,
MS-DOS, PowerPoint, Visio, Visual Basic, Visual C++, Visual InterDev, Visual J++, Visual
Studio, Win32, Windows, and Windows NT are either registered trademarks or trademarks of
Microsoft Corporation in the U.S.A. and/or other countries.

Other product and company names mentioned herein may be the trademarks of their respective
owners.

Program Managers: Rhy Mednick, Susie Parrent
Instructional Designer: Susie Parrent
Subject Matter Experts: David Chesnut, Sam Gill (TechnoWiz), Michel Pahud
Media Management: David Mahlmann
Editing Manager: Lynette Skinner
Editor: Mick Alberts, Jennifer Linn
Production Manager: Miracle Davis
Print Coordinators: Linda Lu Cannon (Write Stuff), Marlene Lambert (Online Training
Solutions, Inc.)
Build Coordinator: Eric Wagoner
Graphic Artist: Scott Serna
Test Lead: Eric Myers
Manufacturing Manager: John Williams
Group Product Manager: Juan Fernando Rivera
Lead Product Manager, System Services and Infrastructure: Edward Dudenhoefer
Manufacturing Manager: Rick Terek

Operations Coordinator: John Williams
Manufacturing Support: Laura King; Kathy Hershey
Lead Product Manager, Release Management: Bo Galford
Group Manager, Courseware Infrastructure: David Bramble
General Manager: Robert Stewart

Module 9: The Transactional Data Access Layer iii


Instructor Notes
This module provides students with a presentation on the transactional data
access layer (DAL). Module 9 is the second of two modules that focus on the
DAL: Module 8, “The Nontransactional Data Access Layer” and Module 9,
“The Transactional Data Access Layer.” The DAL is an application’s means of
access to data services.
After completing this module, students will be able to:
!
Describe the logical design of a transactional DAL and how to apply design
patterns.
!
Describe Microsoft
®
SQL Server
™
, Microsoft Distributed Transaction
Coordinator (MS DTC), and COM+ transactions and synchronization.
!
Describe the Compensating Resource Manager (CRM).
!
Describe the physical design of a transactional DAL and how to use the

technologies presented in this module.

Materials and Preparation
This section provides the materials and preparation tasks that you need to teach
this module.
Required Materials
To teach this module, you need the following materials:
!
Microsoft PowerPoint
®
file 1910A_09.ppt
!
Module 9: The Transactional Data Access Layer
!
Lab 9: The Transactional DAL

Preparation Tasks
To prepare for this module, you should:
!
Read all of the materials for this module.
!
Complete the lab.

Presentation:
60 Minutes

Lab:
60 Minutes
iv Module 9: The Transactional Data Access Layer

Module Strategy
Use the following strategy to present this module:
!
Introduction to Transactional DAL
The purpose of this section is to introduce students to the business problem
and the requirements for transactional DAL.
In the topic “Business Requirements,” emphasize the need for transactions
with either MS DTC–compliant resource managers or for compensating
transactions with CRMs.
!
TechnologiesThe purpose of this section is to introduce students to the
technologies that can be used in the physical design of the transactional
DAL.
The topics covered include the COM+ and SQL Server transaction
mechanism and the CRM architecture.
!
Logical Design of Transactional DALThe purpose of this section is to
identify the two design patterns that might be useful in the logical design of
transactional DAL: Iterator and Composite.
!
Physical Design of Transactional DALThe purpose of this section is to show
how transactions and CRM can be applied to the physical design of
transactional DAL components.
!
Market Purchasing
The purpose of this section is to discuss the logical and physical designs of
transactional DAL in Market Purchasing and to justify the choices made.
By using Component Services, you can present the Market Purchasing DAL
COM+ application. Explain that the nontransactional and transactional DAL

components are all registered in the same COM+ application because all of
the data is physically on one computer. You might also consider presenting
the source code of one of the transactional DAL components. Don’t show
the source code of the mpdaltr.Requisition or mpdaltr.LineItemDetail
classes, because that provides the answers to the lab.
!
Best Practices
The best practices focus on choosing transacted COM+ components rather
than SQL Server implicit transactions in the physical design of the
transactional DAL and the recommendation to use a CRM for
nontransactional data service providers.

Lab Strategy
!
Lab 9: The Transactional DAL
The purpose of Lab 9 is for students to learn to design the transactional
DAL. Students probably will not derive answers that correspond exactly to
the Market Purchasing design. This is acceptable as long as the student
answers are justified and reflect the principles discussed in the module.
Discuss with students their answers to Lab 9.

Module 9: The Transactional Data Access Layer 1


#
##
#

Overview
!

Introduction to Transactional DAL
!
Technologies
!
Logical Design of Transactional DAL
!
Physical Design of Transactional DAL
!
Market Purchasing
!
Best Practices


Module 9 is the second of two modules that focus on the data access layer
(DAL). In Module 8, “The Nontransactional Data Access Layer,” you learned
about data retrieval. In this module, you will learn about data manipulation.
After completing this module, you will be able to:
!
Describe the logical design of a transactional DAL and how to use design
patterns.
!
Describe Microsoft
®
SQL Server
™
, the Microsoft Distributed Transaction
Coordinator (MS DTC), and COM+ transactions and synchronization.
!
Describe the Compensating Resource Manager (CRM).
!

Describe the physical design of a transactional DAL and how to use the
technologies presented in this module.

Topic Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about the transactional DAL
and how to create logical
and physical designs for it.
2 Module 9: The Transactional Data Access Layer


#
##
#

Introduction to Transactional DAL
!
The Business Problem
!
Business Requirements


Transactional data access allows facade layer objects and business logic objects
to manipulate data from the underlying data storage systems. All of the topics
that were covered in the previous module, Module 8, “The Nontransactional
Data Access Layer (DAL),” are relevant in this module as well.

In this section, the transactional DAL will be placed in the proper context of the
business problem. This will be followed by a presentation about the business
requirements of a transactional DAL.
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
what makes up a
transactional DAL.
Module 9: The Transactional Data Access Layer 3


The Business Problem
DAL
Connected Business
Logic Layer
Disconnected Business
Logic Layer
Facade Layer
Web Services Facade Business Facade
Transactional DAL
Nontransactional DAL
User Services
Data
Services


The transactional DAL facilitates both the retrieval and the modification of data

in various formats: database, Active Directory™, and file systems. Business
logic layer objects can access the transactional DAL. In general, the facade
layers do not access the transactional DAL because business logic is usually
involved during transactions.
The transactional DAL receives modification requests from the business logic
layer. The transactional DAL then processes the requests by delegating the
requests to the data services layer. The transactional DAL can return to the
business logic layer either success or failure. If the transaction also involved
retrieving data as a result of updates to the data, a recordset can be returned to
the business logic layer.
Topic Objective
To provide background
about the business problem.
Lead-in
In this topic, you will learn
about the business problem
facing designers who need
to implement a DAL.
4 Module 9: The Transactional Data Access Layer


Business Requirements
!
Transactions
!
CRMs


Transactions
Maintaining the integrity of an application’s data across multiple users and

computers is an important and difficult task. The data access associated with
transferring a student from one course to another is straightforward: you drop
the student from one course and you add the student to the other. When you
scale this operation to an enterprise application, you need an infrastructure to
carry out the transfer. What happens if the drop succeeds and the add fails?
What happens if there is a computer failure immediately after the drop is
executed but before the add is executed? For these reasons, you need an
infrastructure that provides transaction support.
CRMs
Typically, most data services are databases that can participate in a transaction,
such as SQL Server. Unfortunately, not all data services are databases. For
example, Active Directory and Extensible Markup Language (XML) files
cannot participate in transactions unless a special effort is undertaken.
Nevertheless, the business requirement is for these resources to participate in a
transaction. The solution is to implement CRM components for these resources
whose data service providers do not allow them to participate in a transaction,
thus fulfilling the business requirement.
Topic Objective
To provide background
about the business
requirements for
implementing the
transactional DAL.
Lead-in
In this topic, you will learn
about the business
requirements for
implementing transactional
DAL.
Module 9: The Transactional Data Access Layer 5

#
##
# Technologies
!
Transactions
!
Distributed Transactions
!
COM+ Transactions
!
Architecture of CRM


The design of components for the transactional DAL is based on the same data
access technologies as that of the nontransactional DAL. The following data
access technologies were covered in Module 8, “The Nontransactional Data
Access Layer”:
!
Microsoft Data Access Components (MDAC)
!
OLE DB
!
ActiveX
®
Data Objects (ADO)
!
Record
!

Stream
!
Cursor Service
!
Data Shaping Service
!
XML
!
Active Directory Service Interfaces (ADSI)

The design of physical components for the transactional DAL is based on using
transactions. In this section, you will learn about the following transaction
technology topics:
!
Transactions
!
Distributed transactions
!
COM+ transactions

In addition, in this section you will learn about the architecture of the CRM.
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will
review the technologies
associated with
transactional DAL.

6 Module 9: The Transactional Data Access Layer


Transactions
!
Local Transactions in SQL Server
$
Explicit
$
Implicit
!
Avoid Local Transactions When Using COM+ and the
MS DTC
!
Active Directory Transactions


In the transactional DAL, you need to create simple transactions that can affect
one row in one table at a time and complex transactions that can affect multiple
rows in multiple tables.
Local Transactions in SQL Server
By default, SQL Server is in autocommit mode. In this mode, each SQL
statement, such as UPDATE or INSERT, is encapsulated in a separate
transaction as it is run. You can change this behavior by using explicit or
implicit transactions. To use an explicit transaction, you issue a BEGIN
TRANSACTION statement followed by the SQL statements that are to be run
inside the transaction. Then you issue a COMMIT TRANSACTION or
ROLLBACK statement to either commit or roll back the transaction.
To use implicit transactions, you issue the statement SET
IMPLICIT_TRANSACTIONS ON. The next SQL statement you issue, such as

UPDATE or INSERT, will begin a new transaction. The transaction will end
when you issue a COMMIT TRANSACTION or ROLLBACK statement. Then
the next SQL statement will implicitly begin yet another transaction.
Avoid Local Transactions When Using COM+ and the MS
DTC
When using the MS DTC or COM+ transactions, you should avoid using
implicit or explicit transactions since the SQL statements you issue will run
inside the distributed transaction. Beginning new transactions, implicitly or
explicitly, can be semantically confusing and might cause problems with the
distributed transaction.
Topic Objective
To provide a review of
transactions.
Lead-in
In this topic, you will learn
how to design transactions
in the transactional DAL.
Module 9: The Transactional Data Access Layer 7


Active Directory Transactions
Active Directory does not participate in transactions with the MS DTC.
Therefore, any changes you make to Active Directory from withina transaction
cannot be rolled back if the transaction aborts.
However, you can create CRMs to make some of the ADSI interfaces
transactional. For example, when accessing properties in Active Directory it is
possible to cache the properties locally, and to manipulate the properties in the
local cache.
A CRM can use the cache to write properties while the transaction is pending.
When the transaction commits, the CRM writes the properties to the underlying

directory store. If the transaction aborts, the properties are not saved.
8 Module 9: The Transactional Data Access Layer


Distributed Transactions
MS DTC
MS DTC
UPDATE UPDATE


For complex transactions that involve data modifications on multiple rows in
multiple tables on databases that are on multiple computers, there is a protocol
for implementation named two-phase commit (2PC). The name 2PC is derived
from fact that this protocol divides a transaction into two phases: a prepare
phase (variable time) and a commit phase (fixed time).
The MS DTC uses 2PC to manage and implement complex transactions. MS
DTC can be used with various types of transaction participants that adhere to
the XA standard for transactions. In 1991, The X/Open standards group
introduced a standard, named the Distributed Transaction Processing (DTP)
model, and two standard interfaces. The first interface is TX, a standard
application programming interface (API) that applications can use to interact
with a transaction manager. The second interface is XA, a standard API that
transaction managers such as MS DTC can use to interact with resource
mangers such as SQL Server.
You can create explicit distributed transactions with a SQL Server BEGIN
DISTRIBUTED TRANSACTION statement. However, this technique is
counterproductive if the application is using COM+ components to define a
complex transaction, as it should. COM+ uses MS DTC to manage complex
transactions.
Topic Objective

To provide a review of
distributed transactions.
Lead-in
In this topic, you will learn
the details of the physical
design of distributed
transactions.
Module 9: The Transactional Data Access Layer 9


COM+ Transactions
COM+
Transfer
Add
Drop


Implement each individual transaction that is in a complex transaction as a
separate COM+ component, and configure the component as Participating in a
Transaction in Component Services. The complex transaction should also be a
COM+ component configured as Participating in a Transaction in Component
Services, and should create instances of the participating simple transactions by
using the context object. For further information about how to create and
manage transactions, refer to Module 4, “Managing Transactions and State,” in
Course 1907A: Building Distributed Applications for Microsoft Windows 2000
with Visual Basic.
In the preceding slide, there is an illustration of COM+ invoking a complex
transactional DAL component, Transfer, which is composed of two
transactional DAL components, Drop and Add.
Topic Objective

To provide an overview of
COM+ transactions.
Lead-in
In this topic, you will learn
how to create a physical
design with COM+
transactions.