Module 9: The Transactional Data Access Layer

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 applica

Contents

Overview 1

Introduction to Transactional DAL 2

Technologies 5

Logical Design of Transactional DAL 12

Physical Design of Transactional DAL 13

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

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

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

# Overview

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

In this module, you will learn

about the transactional DAL

and how to create logical

and physical designs for it

# Introduction to Transactional DAL

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

The Business Problem

DAL

Connected Business Logic Layer

Disconnected Business Logic Layer

Facade Layer

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

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

In this topic, you will learn

about the business

requirements for

implementing transactional

DAL

! Microsoft Data Access Components (MDAC)

In this section, you will

review the technologies

associated with

transactional DAL

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

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

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

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

Architecture of CRM

CRM Compensator

Log File

1

2 3

CRM Clerk

CRM Worker Application Component

Prior to COM+, it was not possible for nontransactional resources to participate

in MS DTC transactions However, the addition of CRMs in COM+ has made this functionality possible This topic introduces the components of the CRM architecture and their interactions

CRMs provide an alternative to developing full resource managers For example, if you want to make updates to an XML file in the context of a transaction, you have to build a resource manager for XML files The resource manager would be responsible for voting on the outcome of the transaction and for committing or rolling back changes to the XML file, depending on the final result of the transaction Building this type of resource manager is not easy, but the CRM provides an architecture that makes it easier to include resources such

as XML files in transactions

To build a CRM, you must create two components: a CRM Worker and a CRM Compensator The CRM Worker is responsible for performing the work on the resource In the case of an XML file, it updates the XML The CRM Worker also exposes a custom interface for the client component to use For example,

for XML files it might expose a method named WriteToXML The CRM

Compensator is responsible for participating in the two-phase commit It responds to each phase, ultimately committing the changes or rolling them back depending on the outcome of the transaction

Operation of CRM

The first step in the operation of the CRM is the client component’s creation of the CRM Worker The client component then begins using the CRM Worker In the case of the XML CRM Worker, the client component would call the

WriteToXML method to write some XML to a file

Topic Objective

To define how CRM is used

in the physical design

Lead-in

In this topic, you will learn

how and when to include

CRM in your physical

design

The second step is the CRM Worker’s use of another component provided by COM+: the CRM Clerk The CRM Worker uses this component to write log records to a durable log The log records are important because they provide a written record of the work done If a system failure occurs, a recovery can be initiated, and the log records can be used to roll back the changes that were made

When the client is finished and calls SetComplete or SetAbort, the third step

begins The CRM Clerk calls the CRM Compensator so that CRM Compensator participates in the outcome of the transaction The CRM Compensator receives notifications from the CRM Clerk about the outcome of the transaction The CRM Compensator is also used to perform recovery when

or compensate the work that was performed by the CRM Worker

A durable log is provided so that your application resources can write records that survive failures The CRM feature automatically provides recovery on this log file when the application restarts

Logical Design of Transactional DAL

The transactional DAL logical design can use the same design patterns as that

of the nontransactional DAL: the Iterator and Composite patterns

Iterator

The Iterator design pattern allows a client to access a collection of objects without relying on the internal structure of those objects In the DAL, you will frequently be dealing with collections of records being passed back and forth across the system The Iterator is an excellent design pattern to model record collections, and frequently the Iterator is implemented as a recordset

Composite

The Composite design pattern combines multiple types of objects into tree hierarchies or part/whole hierarchies Data often has hierarchical or part/whole relationships For example, in a bill of materials a part might also be an assembly of other parts Although the Composite design pattern is a structural design pattern, it works very well to help organize data Often the Data Shaping Service implements the Composite design pattern

In this topic, you will learn

about the design patterns

that can be applied to a

transactional DAL

# Physical Design of Transactional DAL

In this section, you will learn about the physical design of the transactional DAL In particular, you will learn about designing transactions and a CRM You will then learn how to design the COM+ components that implement the transactional DAL

In this section, you will learn

about the physical design

considerations of a

transactional DAL