|
|
Когда
транзакция подтверждается для многих баз
данных, использующих isc_commit_transaction (), InterBase
автоматически исполняет двухфазное
подтверждение. В течение первой фазы
подтверждения, ядро InterBase опрашивает все
участвующие в транзакции базы данных, чтобы
удостовериться, что они все еще доступны,
затем записывает сообщение, описывающее
транзакцию в поле
RDB$TRANSACTION_DESCRIPTION RDB ситемной таблицы $TRANSACTION ,
затем помещает транзакцию в состояние
неопределенности (limbo).
Именно в течение второй фазы
изменения транзакции фактически
подтверждаются для
базы данных. Некоторые
приложения могут иметь их собственные,
дополнительные требования, чтобы делать
двухфазное подтверждение. Эти приложения
могут вызывать isc_prepare_transaction () чтобы
выполнить первую
стадию двухфазного подтверждения, затем
исполнить их собственные, дополнительные
задачи перед завершением подтверждения
вызовом isc_commit_transaction (). Синтаксис
для
isc_prepare_transaction (): ISC_STATUS
isc_prepare_transaction( ISC_STATUS
*status_vector, isc_tr_handle
*trans_handle); Например,
следующий фрагмент
кода иллюстрирует, как приложение могло бы
вызывать isc_prepare_transaction (), потом после его
собственными подпрограммами, перед
завершением подтверждения по isc_commit_transaction
(): ISC_STATUS
status_vector[20]; isc_db_handle
db1; isc_tr_handle
trans; .
. . /*
Initialize handles. */ db1
= 0L; trans
= 0L; .
. . /*
Code assumes a database is attached here, */ /*
and a transaction started. */ .
. . /*
Выполнение первой фазы двух – фазного
подтвеждения. */ isc_prepare_transaction(status_vector,
&trans); /*
Приложение делает здесь свою какую-то
работу */ my_app_function(); /*
Сечас выполнится подтвержедние второй фазы
*/ isc_commit_transaction(status_vector,
&trans); Это
вообще опасная практика, задерживание второй фазы подтверждения
после завершения первой, потому что
задержки увеличивают шанс, что сетевые
проблемы или
проблемы с сервером могут произойти между
фазами
|
Дизайн: Piton Alien |