Симонов Денисэто как раз и есть чушь. Паттерн с использованием двух транзакций происходит от нежелания закрывать недофетченный курсор, при завершении единственной транзакции которая обновила запись. От наличия нескольких приложений работающих с теми же таблицами это никак не зависит.

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

Симонов Денисну да. А то что это влияет на ширину резалтсета для сортировки конечно не думаем. Да и тащить по сети лишнее это конечно круто, она же жирная выдержит.

Для FB используется ROWS 1, для MS SQL - TOP 1. Увеличивать и так гигантский текст SQL перечислением нескольких десятков полей особо желания не было. Этот так важно?
Симонов ДенисВо-первых это потенциальные грабли, на которые со временем наступишь.

Это понятно
Симонов ДенисЕго наверняка можно упростить, пусть даже не для сервера, а для самого себя чтобы понимать проще было. ДА и не верю я что нельзя придумать чуть более прямую схему фильтрации.
Сомнительно. Все условия разнородные, скорее всего упростить можно только уменьшив количество возможностей, чего не хотелось бы.

Симонов ДенисMolochnikЕсли и селект и апдейт засунуть в одну долгую пишущую транзакцию, то что это никак не повлияет на доступ к тем же таблицам из другого приложения?
а почему это она должна быть долгой? В твоём SELECT выбирается одна жалкая запись. Если это делается долго, то нужно запрос оптимизировать.

В реальности две таблицы большие остальные очень маленькие. С увеличением числа записей скорость выборки в FB ощутимо падает, при наличии 10 тыс в двух больших таблицах еще более менее, но если по 50 тыс то каждый запрос секунды две длится. В MS SQL скорость в первом приближении от размера не зависит. Как я уже говорил таблицы, поля и индексы обеих баз одинаковы и тексты запросов тоже.
Симонов Дениспока не увидел план сказать не могу, но почему-то у меня подозрения что сортировка не планом ORDER идет, а через SORT и тогда это действительно важно

Посмотрел в ibexpert там действительно вначале идет PLAN SORT...
Симонов Денися уверен что это можно сделать. Просто вы проектируете в лоб: одно поле — один фильтр

Да было бы неплохо

kdvMolochnik,
про потоки.
- в одном коннекте у ФБ параллельные операции не работают. Они будут ждать друг друга и выполняться последовательно.
В других серверах точно так же. 1 поток - 1 коннект.

так и устроено один поток - один коннект.
kdvMolochnik,
- если потоки сериализуются по условиям задачи, то зачем они вообще нужны? Ради прикола, написать какой-то интересный в данный момент код?
Работа с базой не является основной целью программы, а полезная деятельность отлично распараллеливается. Критическая секция используется только для выборки данных.
Дегтярев Евгенийсделайте один поток, ответственный за распределение заданий из очереди

Так делать не хочу поскольку в данном случае считаю это излишним усложнением. И зачем тогда вообще сервер баз данных использовать? Сделал всю работу с бд через один поток и радуйся. Работа с файловыми таблицами парадокса быстрее любого SQL сервера на порядок. Там где не используется бд, этот механизм (один поток для обработки информации) я использую часто, но с базой желания нет. Тем более как я уже сказал MS SQL работает как и надо.

Файл конфига FB 3 приложен. Для FB2.5 настроек специальных никогда не делалось.

Вот лог с тестированием одного селекта при 50 тыс записей для FB И MS SQL, работает только один поток.
Первые записи - идет выборка с FB, последние - с MS

Дегтярев ЕвгенийЕсли инкапсулировать логику работы с очередью, то реализации могут максимально использовать особенности выбранных способов хранения и нюансы этой логики не будут размазаны по воркерам
По мне текущая архитектура выглядит логично - каждый поток выбирает подходящую ему незанятую запись и обрабатывает ее столько сколь считает нужным. Ваш вариант с одним потоком обработчиком базы сильно усложняет систему потому, что НЕ ВСЕ записи подходят потоку и время обработки записи потоком неизвестно.

Симонов Денистак у тебя HQBird? Или просто скопировал бездумно?
да тупо скопировал оптимизированный конфиг для суперсервера. Для классик и суперклассик параметры в файле меняю на рекомендуемые оптимизированные с того же сайта.
Дегтярев Евгений400-500ms на получение задачи из очереди это "как и надо"?
ну, скажем так приемлемо. Сама обработка записи может десяток секунд идти
kdvMolochnikКритическая секция используется только для выборки данных.

к чему тогда откровения по поводу потоков и критических секций? Это уже внутреннее дело вашего приложения, которые к работе с БД не относятся.
Да, ни к чему конечно, к работе с БД это не относится. Ошибся и заметил это после отправки вопроса

Dimitry SibiryakovОна логична, но при её реализации ты допустил две ошибки:
1) Длинная читающая транзакция не позволяет видеть изменения флага параллельными потоками,
что на корню рушит логику.

У меня же читающая транзакция read_commited. Если параллельный поток закоммитил данные, неужели читающая другого этого не увидит? Как же у меня она вообще работает тогда? А она работает, причем без исключений

Дегтярев Евгений- поделите записи на группы и отдавайте обработчику нужную
/quot]
Это фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось.
Dimitry SibiryakovЭто в народе называется "дуракам везёт".

Все время же везти не может
MolochnikА она работает, причем без исключений
Это естественно, потому что ты глушишь их секцией except.

Я глушу там просто на всякий случай, по инерции, по логике хуже не будет. Исключения в дебаггере не блокируются и всегда вылазят если что. Если бы были глюки я бы уже давно этим озаботился. А так просто медленно. Если записей 100, то практически незаметно, вот с большим числом сразу это вылезло.

Дегтярев Евгений- поделите записи на группы и отдавайте обработчику нужную
- время обработки тут вообще причем?
Это фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось.
Dimitry SibiryakovЭто в народе называется "дуракам везёт".

Все время же везти не может
Dimitry SibiryakovЭто естественно, потому что ты глушишь их секцией except.

Я глушу там просто на всякий случай, по инерции, по логике хуже не будет. Исключения в дебаггере не блокируются и всегда вылазят если что. Если бы были глюки я бы уже давно этим озаботился. А так просто медленно. Если записей 100, то практически незаметно, вот с большим числом сразу это вылезло.