Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil

В нижеследующем примере на C++ демонстрируется трюк, который часто используется для моделирования принудительного завершения транзакций. Дело в том, что InterBase реализует многоверсионную архитектуру данных (подробнее о многоверсионности данных см. главу "Транзакции Параметры транзакций" (ч 1)) Одной из особенностей такой архитектуры является то, что любые транзакции желательно завершать подтверждением (commit), а не откатом (lollback).

Однако, как правило, транзакцию, в рамках которой выполняется операция чтения данных, не подтверждают, а откатывают. Особенно в случае достаточно длинного участка кода, который генерирует исключения в случае непредвиденных ошибок загрузки информации Поэтому и нужно принудительно завершать транзакции так. как это показано в нижеследующем примере.

try

{

t_db_data_source cn;

_THROto_OLEDB_FAILED(en,attacn("provider=LCPI.IBProvxCter.1,"

"data source=localhost:d:\\database\\employee.gdb;"

"user id=gamer;"

"password=vermut"));

t_db_session session;

// метод create перегружен для разных типов аргумента, поэтому

// можно передавать

// как C++ объект (t_db_data_source), так и IUnknown источника

// данных

_THROW_OLEDB_FAILED(session,create(en)) ,

// запуск транзакции

_THROW_OLEDB_FAILED(session,start_transaction() ) ;

// создаем объект для принудительного завершения транзакции

t_auto_mem_fun_l

_auto_commit_(session, /*commit_retaining=*/false, &t_db_session::commit);

//... теперь, что бы ни произошло, транзакция

// будет "закоммичена"

throw runtime_error("This is my test error");

}

catcn(const exception& exc)

{

cout<< "error:"<

}

По умолчанию библиотека не генерирует исключений, поэтому даже если сбой произошел из-за проблем с самой базой данных, то принудительное завершение транзакции, выполняемое в деструкторе _auto_commit_, не возбудит исключения.

Распределенные транзакции

Еще одним способом инициирования транзакции является подключение сессии к координатору распределенных транзакций. В общих чертах, координатор представляет собой сессию, транслирующую вызовы собственных интерфейсов управления транзакциией в идентичные групповые вызовы интерфейсов списка дочерних сессий. Как правило, от пользователя не требуется никакого участия для подключения к координатору. За это отвечает окружение, у которого пользовательский код запрашивает подключение к базе данных.

На практике распределенные транзакции обычно используются в СОМ+ (MTS) и Microsoft Distributed Query. В первом случае существует следующая особенность. Когда компоненты просят у своего окружения предоставить им подключение к базе данных, то на каждый такой запрос создается отдельная пара источник данных - сессия. Связано это с описанным выше принципом работы пула подключений. Если компонентов, обрабатывающих пользовательский запрос, очень много и они работают с одной и той же базой данных с идентичными параметрами подключения, то имеет смысл один раз получить подключение и потом предоставлять его компонентам. Иначе в распределенной транзакции будет использовано множество сессий, каждая из которых соответствует процессу или потоку на сервере базы данных, что может привести к резкому снижению производительности сервера СУБД.

Использование нескольких сессий в ADODB

Несмотря на то что модель объектов ADODB не предоставляет прямой возможности одновременного использования нескольких сессий с одним источником данных, это ограничение можно обойти. Решение основывается на применение внутреннего интерфейса ADOConnectionConstruction компоненты ADODB.Connection.

void clone_adodb_connection(IDispatch* pCurrentConnection,

IDispatchPtr& spNewConnection)//throw

{

//объявляем типы смарт-указателей для интерфейсов

//конструирования ADODB-подключения

DECLARE_IPTR_TYPE(ADOConnectionConstruction);

DECLARE_IPTR_TYPE(ADOConnectionConstructionl5);

//1 получаем источник данных, привязанный к pCurrentConnection

ADOConnectionConstructionPtr

spConstruct(pCurrentConnection);

ADOConnectionConstruetionl5Ptr

spConstructlS(pCurrentConnection);

if(!spConstruct && !spConstruct15)

t_ole_error::throw_error("Объект - не ADODB.Connection",

E_INVALIDARG);

IUnknownPtr spDataSource;

//берем указатель на OLE DB-источник данных

if((bool)spConstruct15)

spConstruct15->get_DSO(&spDataSource.ref_ptr());

if(!spDataSource && (bool)spConstruct)

spConstruct->get_DSO(&spDataSource.ref_ptr());

if(!spDataSource)

t_ole_error::throw_error(

"ADODB.Connection не инициализирован",E_FAIL);

//2 создаем новую сессию для spDataSource ------------------

IUnknownPtr spNewSession;

IDBCreateSessionPtr spDBCreateSession(spDataSource);

assert((bool) spDBCreateSession);

if(FAILED(spDBCreateSession->CreateSession

(NULL,IID_IUnknown,kspNewSession.ref_ptr())))

{

t_ole_error::throw_error(

"Ошибка создания новой сессии",E_FAIL);

}

assert((bool)spNewSession);