Здравствуйте. У меня такой вопрос по работе компонентов.
Есть 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.
IBDac и подтверждение транзакций
Здравствуйте,
IBDAC по умолчанию препариует запросы которые выполняются в рамках пишущей транзакции, поэтому выполняется CommitRetaining чтобы обеспечить дальнейшую работу с препарированным запросом. Для решения проблемы Вы можете установить свойство TIBCQuery.Options.PrepareUpdateSQL в False. В данном случае IBDAC не будет препаривать запросы пишущей транзакции и будет выполнять Commit вместо CommitRetaining.
IBDAC по умолчанию препариует запросы которые выполняются в рамках пишущей транзакции, поэтому выполняется CommitRetaining чтобы обеспечить дальнейшую работу с препарированным запросом. Для решения проблемы Вы можете установить свойство TIBCQuery.Options.PrepareUpdateSQL в False. В данном случае IBDAC не будет препаривать запросы пишущей транзакции и будет выполнять Commit вместо CommitRetaining.
Спасибо за ответ. Т.е. если я правильно понял, то установив свойство IBCQuery.Options.PrepareUpdateSQL в False, запрос будет подготовлен (PREPARE_STATEMENT) один раз и FREE_STATEMENT будет только после IBCTransaction.Commit;
Подскажите пожалуйста, где найти актуальную справку по компонентам? Просто некоторые свойства не описаны.
Еще раз спасибо.
Подскажите пожалуйста, где найти актуальную справку по компонентам? Просто некоторые свойства не описаны.
Еще раз спасибо.
Если 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 документацию.
- вызывает 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 документацию.