у вас (у заказчика) и весь десктоп на Астре?

. Основная масса компов на Windows, но новые компы заказчика - на Астра (и скоро ещё на РЕД ОС будут).
Попыталис клиентов запускать в Вайн - "ойтыбожежмой", пришлось клиентов переделывать, чтобы и на Виндовз, и под Вайн работали.

даже при одном потоке происходит "Too many concurrent executions of the same request". В чем может быть дело?
Upd. Починили путем однократной подготовки запроса и многократного выполнения подготовленного запроса.

Классическая коллизия при конкуренции за ресурс в многопоточности. В данном случае ресурс - гнездо в кеше запросов. Опять же, сугубое ИМХО

Добавлю, что gbak с -parallel 64 может сделать битый бэкап. Сегодня в качестве эксперимента попробовали - количество строк в одной таблице осталось прежним, но недосчитались около 2000 строк c ID, на которые ссылались другие таблицы по FK. Целесообразность практического применения такого количества потоков под сомнением, но тем не менее.

Добавлю, что gbak с -parallel 64 может сделать битый бэкап.

Перешли на днях на 5. Вроде полет нормальный. Но один сервис, написанный на Go, стал периодически сыпать ошибками вида:
2024/01/18 08:30:19 Too many concurrent executions of the same request
2024/01/19 08:30:19 sql: transaction has already been committed or rolled back
На 4.0.4 такого не было. Сначала грешили на многопоточность сервиса, но даже при одном потоке происходит "Too many concurrent executions of the same request". В чем может быть дело?

Upd. Починили путем однократной подготовки запроса и многократного выполнения подготовленного запроса.

gfix -v -full -user sysdba -password xxx d:\base.fdb

Ошибка в коде валидации, занесёшь в трекер ?

hvlad писал(а) Tue, 23 January 2024 17:40

Ошибка в коде валидации, занесёшь в трекер ?

Можешь занести ? я не особо знаю как это делается. И где можно посмотреть занесённые и статус ,буду ждать исправления. Пока добавил 2-е поле в такие таблицы.

В фибах можно (и, кажись, по умолчанию включено) кэшировать (в рамках коннекта) запросы с привлечением клиента: от текста вычисляется хэш, который хранился на клиенте в паре с дескриптором подготовленного запроса. При совпадени хэша, используется ранее подготовленный запрос.
...
А а FB5 как? Всё то же самое, но на сервере?

МорскойДесант писал(а) Wed, 24 January 2024 10:29

В фибах можно (и, кажись, по умолчанию включено) кэшировать (в рамках коннекта) запросы с привлечением клиента: от текста вычисляется хэш, который хранился на клиенте в паре с дескриптором подготовленного запроса. При совпадени хэша, используется ранее подготовленный запрос.
...
А а FB5 как? Всё то же самое, но на сервере?

Не совсем то же самое, но похоже. И - да - на сервере.

Если, предположим, 100 коннектов и с каждого выполняется один и тот же запрос, то в случае с кэшем фибов будет подготовлено 100 запросов, по одному с каждого коннекта. А в случае с кэшем FB5 будет 100 или один? И будет ли разница в зависимости от Super или Classic?

Но он введён не только для этого, в него также попадают PSQL модули (процедуры, функции, триггеры), так что польза всё-таки есть даже при наличии кеша подготовленных запросов на клиенте.

sim_84 писал(а) Wed, 24 January 2024

Но он введён не только для этого, в него также попадают PSQL модули (процедуры, функции, триггеры), так что польза всё-таки есть даже при наличии кеша подготовленных запросов на клиенте.

А разве процедуры, функции и триггеры не в откомпилированном ("подготовленном") виде хранятся?

Текущий кеш подготовленных запросов больше помогает тем, кто не использует кеширование подготовленных запросов на клиенте.

Но он введён не только для этого, в него также попадают PSQL модули (процедуры, функции, триггеры), так что польза всё-таки есть даже при наличии кеша подготовленных запросов на клиенте.