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

Если при работе сервиса оборвалось связь с 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 и что можно держать сколько угодно транзакцию открытой.