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.
10 Module 9: The Transactional Data Access Layer
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.
Không có nhận xét nào:
Đăng nhận xét