Явные транзакции в ibx

Для более полного управления транзакциями необходимо вызвать TIBTransaction.StartTransaction. Тогда изменения можно не только подтвердить, но и отменить. Commit и Rollback завершают транзакцию и закрывают все ассоциированные с ней наборы данных, а CommitRetaining подтверждает изменения, и стартует новую транзакцию, не изменяя контекста. Побочным эффектом CommitRetaining является то, что набор данных не закрывается и пользователь может продолжать вносить изменения.

Использование таймера и действия по умолчанию

DefaultAction и IdleTimer можно использовать, чтобы периодически подтверждать внесенные изменения и уменьшить вероятность конфликта между транзакциями. Для этого установите IdleTimer в некоторое, не очень большое значение, например 1000 и DefaultAction:=TACommitRetaining. Тогда TIBTransaction будет каждую секунду выполнять COMMIT RETAINING.

Примечание.

1. В случае явного управления транзакциями с помощью StartTransaction и Commit/Rollback не забывайте о таймере. Срабатывание действия по таймеру не позволит вручную завершить явную транзакцию.

2. В файле bdereadme.txt от BDE 5.1 обтекаемо написано, что "Soft commits are a feature of InterBase that let the driver retain the cursor when committing changes." Человек, незнакомый с понятием Soft Commit (он же COMMIT RETAINING), может подумать, что этот режим подтверждает транзакцию, и оставляет открытый курсор вне контекста транзакции. Так вот, это не так. Все действия с БД происходят в контексте транзакции, поэтому COMMIT RETAINING просто клонирует подтверждаемую транзакцию. Наивно думать (как прежде думал я), что можно стартовать транзакцию, закачать данные с сервера, выполнить COMMIT RETAINING и просматривать их фактически в "оффлайне". При работе с данными посредством data-aware компонентов всегда имеется открытая транзакция.

Так что не стоит выставлять IdleTimer:=1 и DefaultAction:=TACommitRetaining в надежде на быструю "закачку" данных, завершение транзакции и последующий просмотр данных во внутреннем буфере. Все будет гораздо хуже: каждую 1 миллисекунду (на самом деле, несколько реже) программа будет подтверждать изменения на сервере, что приведет к существенному росту сетевого трафика.

Если же DefaultAction имеет значение TACommit или TARollback, то после первого же действия по таймеру транзакция будет завершена.

Использование CachedUpdates

Установка CachedUpdates:=True несколько изменяет идеологию выполнения транзакций. Как и в случае CachedUpdates:=False, транзакция все равно является открытой на протяжении работы с данными через data-aware компоненты, но изменения вносятся только при вызове ApplyUpdates.

В случае CachedUpdates:=False измененные данные сразу отправляется на сервер и, если не происходит конфликта, вызванного другой транзакцией, хранятся там до осуществления COMMIT/ROLLBACK. Таким образом, конфликты могут быть выявлены еще до того, как пользователь захочет сохранить все внесенные изменения на сервере. В случае CachedUpdates:=True все изменения накапливаются в локальном буфере и при ApplyUpdates единым пакетом отправляются на сервер, после чего подтверждаются.