Заинтересовал меня такой концептуальный :) вопрос...
Есть система, построенная по принципу 3-звенки. Соответственно есть сервер приложений (далее СП), который висит как служба и обслуживает клиентские подключения. Клиенты, при подключении указывают с какой "конфигурацией" (а-ля БД) они хотят работать, и СП по этому коду создает соединение с нужной базой, ну и обслуживает запросы.
На каждое подключение создается свой поток на СП, в котором есть коннекшен к СУБД и создаются/удаляются объекты типа ADOQuery. В каждом потоке есть кеш всяких описаний. Например, шаблоны отчетов хранятся в базе, при первом запросе от клиента на получение шаблона, он помещается в кеш, и , пока кеш не будет сброшен, при следующих клиентских запросах шаблон будет выдаваться из кеша.
Но кеш у каждого потока СП разный. То есть, если с одной "конфигурациеей" работает 100 клиентов, то содержимое кеша различных потоков повторяется.

Получается: насколько выгодно иметь общий кеш, ведь при выигрыше по памяти (шаблон в моем примере будет храниться в кеше в одном экземпляре) возникнет очередь обращений к кешу за нужным объектом? А это межпоточная синхронизация - надо тормозить один поток, пока с кешем работает другой.

Как вы думаете?

softwarer Alex SПолучается: насколько выгодно иметь общий кеш, ведь при выигрыше по памяти (шаблон в моем примере будет храниться в кеше в одном экземпляре) возникнет очередь обращений к кешу за нужным объектом? А это межпоточная синхронизация - надо тормозить один поток, пока с кешем работает другой.
С каких это пор чтение из кэша стало требовать эксклюзивной блокировки, да еще и на уровне кэша в целом?

Если так реализовывать, то конечно кэша не нужно. И сервера приложений тоже не нужно. Лучше писать что-нибудь на акцессе..

Alex SНа каждое подключение создается свой поток на СП, в котором есть коннекшен к СУБД и создаются/удаляются объекты типа ADOQuery.
А вот это напрягло бы меня куда больше, нежели какие-то кэши.

Роман ДынникЕсли опасаетесь, что не будет хватать производительности по обращению к кешу - масштабируйте кеш.
Запросы направляются к Observer-у, который определяет доступные кеш-сервисы и распределяет запросы по ним.
Ориентируйтесь также на асинхронные вызовы.
Ну в смылсе не один и не 100 кешей на 100 клиентов,а, например, 10?

softwarerС каких это пор чтение из кэша стало требовать эксклюзивной блокировки, да еще и на уровне кэша в целом?
Может, я что-то недопонимаю, но как я буду из разных потоков (TThread) обращаться к одному глобальному экземпляру классу и что-то в нем искать?
Такие вещи как критические секции, обычно и обеспечивают "потокобезопасность", а что есть "EnterCriticalSection(FLock)" - остановка (блокировка) потока, пока другой поток не выйдет из критической секции. Другое дело, что обычно эти механизмы обеспечения потокобезопасности скрыты.

softwarer
А вот это напрягло бы меня куда больше, нежели какие-то кэши.
Вы имеете в ввиду, что надо одно соединение на все подключения?
Мои аргументы против:
- Многие заказчики хотят видеть всех юзеров в результатах sp_who2 (MsSQL выдает подключения к серверу)
- Одно подключение не резиновое. В нем также возникают блокировки потоков (если оно (подключение) реально одно)
- Не хочу связываться с клонированием коннекшенов, что возникает при т.н. асинхронной работе, когда ADO решает, что ему надо бы создать еще одно подключение для параллельной обработки нескольких запросов.
- Возникают проблемы с временными таблицами, которые видны только в "своем" коннекшене.
- В общем случае, из одного СП подключения к разным серверам
- В общем случае, из одного СП подключения с разными правами на сервере
- может еще чего, сразу не вспомнил.

Petro123 Alex SМожет, я что-то недопонимаю, но как я буду из разных потоков (TThread) обращаться к одному глобальному экземпляру классу и что-то в нем искать?
Такие вещи как критические секции, обычно и обеспечивают "потокобезопасность", а что есть "EnterCriticalSection(FLock)" - остановка (блокировка) потока, пока другой поток не выйдет из критической секции. Другое дело, что обычно эти механизмы обеспечения потокобезопасности скрыты.

такие вещи как 3-е звено, пул коннектов и т.д. само по себе "критические секции" - ограничивают потоково-параллельную работу пользователей с сервером.
Оно тебе надо было? "Слабое" среднее звено?

Так пока ничего такого и нет! Ни пула, ни межпотоковой синхронизации, ни одного коннекшена на всех. Сейчас сервер приложений почти полностью "потоконезависимый" :). Почти, потому что есть единственная критическая секция синхронизации потоков, когда в целях администрирования (монитор подключений) запрашиваются параметры всех потоков. И то с проверкой потока на "занятость".
Вот я и думаю - стоит заморачиваться или нет.

А насчет "религиозных войн" по поводу среднего звена - давайте не будем снова расчехлять копья ;) . Считайте мой сервер приложений аналогом оракловой службы TNSListener (чем она не третье звено в _классической_ клиент-серверной архитектуре? :) )

Petro123 Alex S
А насчет "религиозных войн" по поводу среднего звена - давайте не будем снова расчехлять копья ;)
давайте не будем :).
Только вопрос ваш звучит странно тогда:
- создали третье звено полностью "потоконезависимый" (про ЗАЧЕМ тогда - не будем)
- в данном случае (среднее звено не решает бизнес-задачи) - никакой кэш не нужен.

Или всё-таки среднее звено - "тормозит"? ;)

ЗЫ. Сначала делаем препятствия, а потом их героически "обходим".

Про ЗАЧЕМ:
1) Абстрагирование от типа сервера на настоящий момент:
Microsoft SQL Server 2000
Microsoft SQL Server 2005
MSDE
Oracle 8
Oracle 9
Oracle 10
IBM DB2 v8
2) В СП сосредоточены функции:
-ограничения доступа
-ПОЛНОГО журналирования событий
3) С рабочих мест вынесены ВСЕ драйверы СУБД, что особенно актуально в случае Oracle, DB2. Наиболее часто практикуется забуск клиентского приложения (~4Mb) с сетевого ресурса. Никто не бегает по этажам и зданиям для смены версий и настройки.
4) Организована шифрация всего траффика между клиентскими приложениями и СП, а это наибольший отрезок сети т.к. между СП и СУБД он минимален, либо его нет (на одной машине).
5) Варианты подключения через HTTP,HTTPS (встроено в клиентское приложение) в том числе с выходом через прокси сервер.
6) "КроссСерверные" конфигурации - одно клиентское подключение работает с данными нескольких СУБД (один справочник на одном, другой на другом ...) в т.ч. на различных типах СУБД
7) Уменьшение траффика от клиентской станции:
- из-за формализации выполнения операций (посылается короткая команда, выполняющая бОльшие операции между СП и СУБД
- из-за пакетного механизма передачи наборов данных между СП и клиентом
- из-за упаковки траффика алгоритмами компрессии
8) Гладкое переподключение при сбоях в сети
9) может чего не вспомнил

Кеш нужен по любому :) Вообще, это не напрямую связано с 3-звенкой, скорее с таким принципом построения системы, как "работа по описаниям" , хранящимся в базе. Шаблоны отчетов, DFM форм, описания атрибутов документов, методов из обработки и т.п.
В клиентский exe-ник не "Вкомпилируются" формы документов, шаблоны отчетов и т.п. - он берет их из базы. Меняются они там при сменах версий, т.е. редко. Вот эти описания и кеширются.

+ Про ЗАЧЕМ:
Собственно, это вытекало из моих объяснений, но дополню:

x) СУБД не видны из сети. Законнектится к ним, например с помощью sqlplus.exe или osql.exe невозможно. Иногда это встречается в требованиях по безопасности в дотошных (как правило иностранных) организациях.
Да и вообще полезно для спокойного сна ;)

UrryMcA автор- Многие заказчики хотят видеть всех юзеров в результатах sp_who2 (MsSQL выдает подключения к серверу)

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

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