IBDac и подтверждение транзакций

[raMZES]

Здравствуйте. У меня такой вопрос по работе компонентов.

Есть IBCQuery, две IBCTransaction - одна:

Transaction1
nowait
read_committed
rec_version
read

Другая:

Transaction2
nowait
read_committed
rec_version

К IBCQuery, в качестве Transaction указана первая - Transaction1, читающая, в качестве UpdateTransaction - Transaction2, пишущая. Режим в IBCConnection AutoCommit := true и у IBCQuery тоже.

После изменения записи в Гриде, серверу отсылается комманда COMMIT_RETAINING

У меня вопрос. Почему именно COMMIT_RETAINING? Зачем? Почему не COMMIT_TRANSACTION

Ведь для этого, я так понимаю, у компонента IBCQuery как раз и есть 2 транзакции. В контексте одной данные читаются с сервера, а в контексте другой, UpdateTransaction - записи обновляются и транзакция, в данном случае, сразу подтверждается. Другое дело, когда у компонента только одна транзакция и COMMIT_RETAINING отправляется для подтверждения изменений без закрытия. Тут уж ни как.
Для InterBase с 7.х COMMIT_RETAINING не страшен. Только многие из тех, с кем я общаюсь используют FireBird, а для него COMMIT_RETAINING будет плачевным в плане производительности, т.е. удержания транзакции, накапливании мусора и т.д. Если пользователь будет часто сохранять изменения по COMMIT_RETAINING, могут возникнуть ошибки вроде Too many savepoints

Для интереса я установил триальную версию AnyDAC. Там транзакция после изменения записи сразу подтверждается. Т.е. UpdateTransaction сразу делает COMMIT_TRANSACTION.

FIBPlus от http://devrace.com тоже является двутранзакционным. И тоже завершает обновляемую транзакцию по COMMIT_TRANSACTION.

Можно ли где нибудь настроить нормальное поведение компонентов IBDac?

Спасибо.

P.S. Вырезка из источника IBase.ru
---------------------
Не рекомендуется слишком часто завершать одну и ту же транзакцию по retaining, или производить в каждом таком "интервале" много изменений - это чревато появлением ошибки 287 "too many savepoints" в interbase.log.
Кроме того, транзакция, завершаемая по CommitRetaining, с точки зрения сервера и сборки мусора выглядит как длительно работающая транзакция SNAPSHOT (то есть, CommitRetaining в этом плане не является аналогом Commit). А это значит, что CommitRetaining фактически препятствует сборке мусора, независимо от типа транзакции - Snapshot или ReadCommitted.

[AndreyZ]

Здравствуйте,

IBDAC по умолчанию препариует запросы которые выполняются в рамках пишущей транзакции, поэтому выполняется CommitRetaining чтобы обеспечить дальнейшую работу с препарированным запросом. Для решения проблемы Вы можете установить свойство TIBCQuery.Options.PrepareUpdateSQL в False. В данном случае IBDAC не будет препаривать запросы пишущей транзакции и будет выполнять Commit вместо CommitRetaining.

[raMZES]

Спасибо за ответ. Т.е. если я правильно понял, то установив свойство IBCQuery.Options.PrepareUpdateSQL в False, запрос будет подготовлен (PREPARE_STATEMENT) один раз и FREE_STATEMENT будет только после IBCTransaction.Commit;

Подскажите пожалуйста, где найти актуальную справку по компонентам? Просто некоторые свойства не описаны.

Еще раз спасибо.

[AndreyZ]

Если TIBCQuery.Options.PrepareUpdateSQL установлен в False, IBDAC выполняет следующие шаги:
- вызывает prepare модифицирующего запроса (insert, update, delete);
- выполняет запрос на сервере;
- выполняет commit запроса;
- вызывает unprepare запроса.
Если же TIBCQuery.Options.PrepareUpdateSQL установлен в True, IBDAC выполняет следующие шаги:
- вызывает prepare модифицирующего запроса (insert, update, delete);
- выполняет запрос на сервере;
- выполняет commitretaining запроса.
IBDAC документация поставляется с IBDAC, а также досупна на нашем веб-сайте здесь (в разделе Documentation and Demo): http://www.devart.com/ibdac/download.html . Если Вы не можете найти описание какой-то опции или метода, пожалуйста пишите нам, мы будем добавлять описания в IBDAC документацию. Мы добавим описание опции PrepareUpdateSQL в IBDAC документацию.