При высокочастотной ставки записей в базе имеет ли смысл кроме коннектов держать еще открытые транзакции и может препаренные запросы в каждом флаконе? Инсерты однородные, редко может понадобится еще дополнителные ставки. Коммит(Рет) нужно после каждой.

Если при работе сервиса оборвалось связь с FB, можно как-то ловить это в реале, кроме фэйла уже при вызове isc_start_transaction итп?

Спасибо всем кто откликнулись и изложили мысли.
Оставил вопрос вчера к концу рабочего дня и только сегодня взглянул.

Данные приходят по сетке (tcp/udp) с каждого девйса где-то раз в 30сек, практически равномерно/рандомно распределенные.
Принимаю пакеты серверами Indy (TIdTcpServer, TIdUdpServer).
Выделяется поток где обрабатывается каждый входящий пакет.
Хотелсь бы обслуживание хотяб 1000 клиентов на одном ноде (это примерно 33 ставок в секунду).

Щас работает, но нагрузка маленькая. Есть пул коннектов. При обработке стартует транзакция, запрос ставки и коммит.
Вот и пришла и идея повышения марсштбируемости путем добавения в пула еще и по долгой ридкоммитед транзакции и препаренного запроса для каждого коннекта. И после обработки пакета делать коммит ритэйн. Плохо ли? Можно в принципе раз там на 1000 ритэйн коммитов делать и коммит и заново стартовать транзакцию и препарить запрос.

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

Или держать всегда готовые потоки-обработчики как workerы в apache?

Насчет обрыва связи с ФБ сервером, скорее в продакшине будет локально, но хотелось обработать и потеря коннекта, когда было отключения сокета, попытатся восстановить связь. Есть в fbclient-е такой колбэк? Щас могу ловить при старте транзакции/запрса по коду ошибки статуса.

препарированные запросы не привязаны к транзакции и коммит их не
уничтожает
хм... вот спасибо. а я думал что они дестроится...

СУБД для задачи таки выбрана неверно
на чем знаем, на том и пишем :)

Дмитрий вроди делал тесты: http://www.ibase.ru/devinfo/instest.htm
Результаты неплохие.

kdvзачем тебе вообще нужен commitRetaining???
Дмитрий, я думал что можно выиграть в производительности если делать только CommitRetaining вместо Commit;Start; при обработке пакета.
Буду переделывать на пул коннекшинов + препаренные запросы + кототкиу транзакции: старт/ставка/коммит. Так лучше?

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

kdv"производительность" commitretaining
Так будет только фиксация изменений без старта другой транзакции (что я думал непростая операция).
Помню Еманов говорил к релизу 2.0 или 2.5 что были сделаны оптимизации по CommitRetaining и что можно держать сколько угодно транзакцию открытой.

Понял, спасибо всем! Значит будет чистый коммит.
Насчет параметров транзакции, если будут короткие, только ставки, лучше read commited version? или по барабану.

Рустам, анализируя ваши мысли, хотелось уточнить...
Гаджимурадов РустамА вот отпрепаренные запросы легко переживают коммит, их повторно препарить не нужно, только параметры меняй и повторно Exec-Commit.

- isc_start_transaction - получаем trans_handle
- isc_dsql_prepare(trans_handle) - хочет как параметр trans_handle
- isc_dsql_execute(trans_handle) - здесь как бы первый раз должно быть ок
- isc_commit_transaction - убиваем trans_handle
- isc_start_transaction - получаем новый_trans_handle
- isc_dsql_execute(новый_trans_handle) - это будет работать, да?

Просто я из делфей, почти везде видел UnPrepare при Transaction.Destroy;
Щас нашел одну простую лиюбу, переделываю под себя чтоб были живучие препэйры.

Тогда, если препэйр не зависит от транзакции лучше бы требовали database_handle вместо transaction_handle в isc_dsql_prepare.

Дмитрий, ок, может в TIbTransaction все тип-топ, а вот в найденом либе под лазаруса не торт. Переделываю успешно :)
А че не надо в апи лезть, мне интересно, особенно новый ооп в тройке. Часто смотрю что творит Фернандос в интерфэйс паскаля.