Известно, что Firebird позволяет иметь несколько транзакций в соединении. Но вопрос, а если эти разные транзакции имеют каждая свою процессорную нить? Транзакции независимы друг от друга.
Применительно к Firebird 3.0 будет ли работать корректно?

fraksПохоже вопрос возник из-за многопоточности клиента. У меня однопоточное, посему я с этим вопросом не сталкивался.
Да, именно так. Web-приложение. Вопрос встал потому, что пул имеет конечное число соединений. А, допустим, нагрузка возросла и соединений стало недостаточно. Тогда имеет смысл пустить транзакцию в имеющемся соединении рядом с другой.

rdb_devЩиче, ответ здесь: 17581937
Спасибо

Ivan_PisarevskyЩичеТогда имеет смысл пустить транзакцию в имеющемся соединении рядом с другой.спорный вопрос, я бы так не стал делать. Одно дело когда в один коннект пихается куча транзакций одного потока, все ясно и понятно, а тут мне видится, что встанет оно в "клинч".

"Много" соединений - это сколько в штуках?

Для отдельных нитей (отчетов, например) поднимаю отдельные коннекты, мне так как-то спокойней. К тому же они частенько уходят на вспомогательный сервер.

Зависит от конкретного процессора. Имеем одну нить обрабатывающую поток запросов от клиентов. Допустим 100 их одновременно.
Запрос требует обращения к БД. Отстреливаем нить для обращения. Отработает - вернет данные основной нити. Проц четырехъядерный (пример). Следовательно, разводить сто соединений к БД становится абсурдом. Надо 4-5. Но что делать, когда клиенты навалились большой толпой и все соединения заняты? В очередь ставить или пустить параллельно с уже работающими?
Вот этот вопрос меня волнует.

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

Щиче
На чём таком вы пишите Web приложение? Вы что пул коннектов самостоятельно реализуете. Насколько мне известно пул что в Java, что в .NET не позволит использовать в другом потоке соединение которое не было возвращено в пул.

Есть язык программирования D. У него есть только Postgres драйвера, а стандартизованного обращения к СУБД нет совсем. Поскольку мне с ФБ расставаться не хочется - пишу собственную реализацию.

Симонов ДенисЩиче,

и вообще ограничивать количество коннектов в пуле какой-то малой величиной (<100) не имеет смысла, хотя бы потому что сервер БД может находится где угодно и клиентское приложение ничего не знает о количестве ядер на севере. Пусть там ось и Firebird сами разбираются. Делайте пул как я сказал: если в пуле нет коннектов, то создаётся новый. Обычно у неактивных коннектов есть ещё время жизни, например 60 сек, после которого коннект удалятся из пула. Почитайте как работают пул в Java или .NET.

Принято. Действительно надо заняться самообразованием.

D_nub, за всю Одессу не скажу, но мне нравится. Я вырос из Дельфи, потом ушел на Java. В этом языке есть почти все из того, что мне нравится в одном языке и отсутствует в другом. Тему предпочитаю не развивать здесь, чтобы не провоцировать холивар.

Ivan_PisarevskyПочему абсурдно? у нас на пару шестиядерников пара сотен коннектов. Коннект ведь необязательно напрягает проц-память-диск-сеть по полной. Кто-то передает данные, кто-то ждет пока клиент соизволит сфетчить хвост данных, кто-то ждет дискового ИО, кто-то сетевого ИО, что-то читает из кэша, кто-то сортирует через темп и т.п.

Как по мне, так абсурд делать кол-во коннектов не более чем процовых ядер, обычно раньше всех исчерпываются ресурсы дискового ИО, потом размер ОЗу и только потом процы. Даже если каждый коннект активно что-то делает и то можно множить кол-во ядер на 10, а если они малоактивные, то и на 100.

Давайте представим, что такое коннект. Это всегда выделение памяти. Раз. На классике отстреливается полноценный процесс, на суперсервере нить, два.
Далее, у нас пошел пик подхода клиентов. 100 коннектов разом. И все активны! В самом дохлом месте, на обращении к дисковому ИО. ОЗУ тоже может кончится, значит пойдет своп. Т.е. все сто повиснут. Ладно, отработали. Теперь у нас сто соединений неактивных. А обращения в этот момент упали до 10-15. Но они все равно будут медленными, потому что у нас вся ОЗУ сервера СУБД загажена мусором, который остался от предыдущего ажиотажа.
В документации к любой СУБД написано, что лишние соединения открывать нежелательно! Поэтому пулы имеют верхний предел. Обычно 16-32 по умолчанию.

Ivan_PisarevskyНе понял логики, если коннект уже вернулся в пул, значит там уже ничего не должно быть лишнего, никакого мусора, или тот кто управляет таким пулом полный бездарь. Пустой же коннект не такое дорогое удовольствие.
Коннект не зависит от того, вернулся он в пул или нет. Он либо работает, либо нет. 100 коннектов работают одновременно == мы накрылись.

Ivan_Pisarevskyтут можно вполне прикинуть "столбиком", сколько коннектов не свалят сервер в своп, зная на своем опыте сколько обычно съедает один.

А меня как раз интересует ситуация, когда я столбиком посчитал n коннектов, а у меня в определенный момент времени 2*n, а то и n^2 запросов. При том, что в следующий заход может быть n/10, n и вообще 1. В другой снова n+m. Такое в Web вполне может быть. Их однозначно надо ставить в очередь при превышении n . Вопрос как это сделать.
Java пул ограничен сверху по числу соединений именно по этой логике.

Dimitry Sibiryakov, как раз Oracle :)