Точно нет? Ну то есть вот если хоть один другой вариант найдётся - ты посыпешь голову пеплом и впредь заречёшься писать прежде чем думать?

Чтобы просвещать, нужно хоть как-то представлять задачу. "Дофига" - это хотя бы примерно сколько?

Ну, тут вопрос - каких именно соединений. Речь может идти о сессиях в БД или о tcp/соединениях операционки. Но в любом случае в таких условиях стратегия "сразу же гробить" неэффективна по сравнению со стратегией "разделяя, эффективно использовать". На пальцах:

• допустим, одна пользовательская операция потребляет в среднем X ресурсов (процессор, память итп)
  
• допустим, мощность основного железа 10'000 * X (то есть в идеале оно может обслуживать 10'000 постоянно активных клиентов)
  
• допустим, операционка, БД или что-нибудь в этом духе ограничивает количество одновременных соединений 1'000
  
• допустим, инициализация и завершение соединения потребляют в среднем Y ресурсов.
  

Давай возьмём за эталон лузерства решение "1000 счастливчиков подключились и работают, остальные сосут". В этом режиме ресурсы сервера утилизируются на 10%, то есть 90% уходит впустую. Показатель полезной нагрузки - 1000 операций в единицу времени.

Рассмотрим твоё решение. В этом случае одна операция требует уже X + Y ресурсов. Что будет с сервером? Тут уже начинает зависеть от того, что именно за ресурсы. В наилучшем случае он будет делать те же 1000 операций в единицу времени, но утилизация повысится до 10*(X+Y)/X процентов (так будет, например, если операции требуют почти исключительно процессора, и по нему запас). В наихудшем случае утилизация останется той же, но он будет делать всего 1000*X/(X+Y) операций в единицу времени. То есть пропускная способность уменьшится даже по сравнению с лузерским вариантом! В реальности скорее всего будет нечто промежуточное - пропускная способность уменьшится, но не так сильно, утилизация увеличится, но не так сильно.

На практике этим ты предлагаешь купить следующее: вместо "1000 счастливчиков, 9000 сосут" будет "10000 сосут, но чуть менее обидно". С точки зрения пользователя каждая операция будет занимать в 10-20-50 раз дольше, чем могла бы. Можно ли так работать? Ну да, в принципе, конечно, можно. Я в такой ситуации просто приношу на работу книжку и сижу, читаю.

Что бы лично я сделал вместо этого. Я бы поставил 20 промежуточных прокси - они простые и дешёвые. Клиенты соединяются на прокси по 500 штук на каждого, лимит в 1000 соединений не нарушен. Прокси соединяются с БД, тратя на это 20 * N соединений. N выбирается исходя из оптимальной работы сервера. Прокси диспетчеризует запросы так, чтобы наилучшим образом загрузить сервер (например, упаковывает разные в один батч). Лимит в 1000 соединений опять же не нарушается. Итого: сервер загружен по полной, 10'000 счастливчиков спокойно и эффективно работают, все счастливы. По цена/качество этот вариант кроет "одноразовые подключения" как бык блоху.

Для упрощения рассуждений я говорю о постоянно активных клиентах, то есть работающих в цикле "отправил запрос - получил ответ - сразу же отправил следующий". Реальные клиенты, конечно, обычно ждут пользователя, но с этим всё просто: если клиент активен в среднем k% времени, то N "ждущих клиентов" по потоку обращений эквивалентны kN "постоянно активных", можно рассуждать в терминах последних и не думать о k.

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


Ну, есть такое в Oracle, называется shared server mode. Но это ответ для случая, если лимит по количеству соединений. Лимит по tcp соединениям это преодолеть не поможет.

Весьма спорно. Напомните: вот лежит некий плагин (ну то есть jar-ник или нечто аналогичное в любом другом формате). Java хотя бы научилась загружать его без необходимости явно перечислять стартовые классы, инициализация которых должна быть выполнена?


Вы так говорите, будто это нечто особенное.

Если у ТС есть колёса и руль, это не означает, что нет ничего кроме колёс и руля. Он задаёт архитектурный вопрос и не задал никаких ограничений на "только КС". Да и кроме того, прокси - вовсе не обязательно нарушение КС.

ViPRos,

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

Нет. Подход "всё на ХП" - это отрыжка больного на голову MSSQL, которая появилась только потому, что они не могли сделать адекватной работы СУБД в других режимах и предпочли за счёт маркетоидов прорекламировать багу как фичу.

Так или иначе, контракт между БД-частью и БД-клиентом - вопрос архитектуры. Разработчик выбирает тот вариант, который соответствует задаче.

Секурность на уровне ХП - это заведомо хрупкое решение. API - хорошее слово. ХП - это существенная часть API, но они не в состоянии дать адекватное решение ряду стоящих задач, поэтому подход "всё на API" годится либо для демо-примеров в книжках, либо для производства инвалидов.