Ранее при использовании транзакций из служб COM+ можно было увидеть настройку уровня транзакций в окне свойств класса в Snap-In службы компонентов. Эта настройка позволяет задать уровень поддержки транзакций, который службы COM+ будут предоставлять стандартному компоненту COM.
Иначе в .NET уровень поддержки транзакций в сборке можно определить не с помощью графического окна в snap-in службы компонентов, а программным путем с помощью атрибута
Transaction
, определенного в пространстве имен
EnterpriseServices
. В примере ниже
мы определяем, что следующий класс прокси должен поддерживать транзакции. При заданном значении атрибута компонент будет сконфигурирован для поддержки транзакций, когда он импортируется в службы COM+ с помощью
RegSvcs.exe
.
[Transaction(TransactionOption.Supported)]
public class ProxyClass:ServicedComponent {
}
Supported
является только одним из нескольких значений, которые можно присвоить атрибуту
Transaction
компонента. Фактически, существует четыре значения, которые представлены в перечислении
TransactionOption
, являющемся частью пространства имен
System.EnterpriseServices
.
□ Когда атрибут
Transaction
класса задан как
Disabled
, службы COM+ не предоставляют транзакционной поддержки для класса, даже если такая поддержка определена где-то в коде. (Другими словами, вызовы этого класса, сделанные для
ContextUtil
с целью фиксации или отмены транзакций, игнорируются. Мы познакомимся с
ContextUtil
в следующем разделе.)
□ Когда атрибут
Transaction
класса задан как
NotSupported
, такой класс не вовлекается в транзакции, запускаемые его клиентами, другими словами он не помещается в их контекст. В данной конфигурации объекты этого класса не определяют, будет ли вызываемая транзакция фиксироваться или отменяться.
□ Когда атрибут
Transaction
класса задан как
Supported
, объекты этого класса могут вовлекаться в контекст транзакций своих вызывающих клиентов, если эти вызывающие клиенты на самом деле начинают транзакцию. Такой объект не может самостоятельно порождать транзакцию.
□ Когда атрибут
Transaction
класса задан как
Required
, службы COM+ знают, что объекты этого класса могут выполняться только в контексте транзакции. Если такой объект вызывается клиентом, имеющем транзакционный контекст, объект наследует контекст транзакции клиента. Если, однако, объект вызывается клиентом, который не имеет транзакционного контекста, службы COM+ создают контекст для этого объекта.
□ Когда атрибут
Transaction
класса задан как
RequiresNew
, службы COM+ создают новую транзакцию для класса каждый раз, когда он вызывается. Даже если клиент объекта уже имеет транзакцию, службы COM+ создают новую транзакцию для серверного объекта. Как можно догадаться, классы, сконфигурированные подобным образом, способны отменить только свои собственные транзакции, а не работу своих клиентов.
На практике большинство разработчиков используют только одну или две из этих настроек. Значение
Supported
подходит для классов типа класса
Settings
, которому нужно будет обслуживать классы с транзакциями и без транзакций. Для большинства других транзакционных классов можно справиться, задавая значение
Required
. Однако все-таки может возникнуть ситуация, где потребуются одно или несколько составных значений, дополнительную информацию можно найти в книге "Professinal Windows DNA Programming" (ISBN 1-861004-45-1) издательства Wrox Press.
Кодирование транзакций с помощью ContextUtil
Модификация класса с помощью атрибута
Transaction
является только частью того, что необходимо сделать, чтобы подготовить его для участия в транзакции. Надо также определить, как каждый метод
в этом классе ведет себя, когда он вызывается как часть транзакции. Это осуществляется с помощью класса
ContextUtil
из пространства имен
System.EnterpriseServices
.
Проще говоря, класс
ContextUtil
предоставляет контекст транзакции. Когда имеется ссылка на контекст транзакции, можно явно заставить этот контекст зафиксировать или отменить транзакцию. Методы, которые необходимо вызвать для фиксации или отмены транзакций, представляются как методы класса в классе
ContextUtil
, поэтому не придется создавать экземпляр класса
ContextUtil
, чтобы их вызвать.
В качестве примера сделаем краткий обзор фрагмента кода, приведенного ниже.
public bool PlaceOrder(bool CommitTrans) {
// Попытка работы
try {
if (CommitTrans) {
// Эта транзакция должна быть зафиксирована
// шаг 1 — увеличить число единиц продукта ID=2 на 10
IncreaseUnits(2, 10);
// шаг 2 — сократить запас продукта ID=2 на 10 единиц
ReduceStock(2, 10);
} else {
// Эта транзакция должна быть отменена
// шаг 1 — увеличить число единиц продукта ID=5 на 5 единиц
IncreaseUnits(5, 5);
// шаг 2 - сократить запас продукта ID=5 на 5 единиц
ReduceStock(5, 5);
}
// Если все прошло хорошо, завершить транзакцию.
ContextUtil.SetComplete;
return true;
}
// Этот код выполняется, если встречается ошибка.
catch (Exception е) {
// Отменить работу, которую выполнила эта функция.
ContextUtil.SetAbort;
return false;
}
}
Что здесь происходит?
Мы имеем две транзакции, которые обрабатываются в зависимости от значения
CommitTrans
. Для любой транзакции
PlaceOrder
вызывает два метода, которые оба соединяющиеся с базой данных
Northwind
, чтобы сделать изменения в таблице
Product
. Метод
ReduceStock
сокращает объем запасов в столбце
UnitsInStock
, метод
IncreaseUnits
увеличивает значение столбца
UnitsOnOrder
. Для обоих методов первым параметром является
ProductID
в строке, которую нужно изменить, второй параметр есть величина, на которую мы хотим изменить соответствующий столбец.
. Первая транзакция должна быть зафиксирована, так как уровень запаса для
ProductID=2
равен 17, следовательно, можно удалить десять элементов и все еще иметь оставшийся запас. Однако вторая транзакция обречена на отказ так как
ProductID=5
не имеет запаса элементов и существует ограничение на столбец
UnitsInStock
, которое не позволяет значению становиться меньше нуля. Это означает, что можно проверить, будет ли транзакция отменяться или нет. Не должно быть никаких проблем с вызовом
IncreaseStock
, поэтому можно увидеть, что транзакция была отменена, проверяя значение столбца