Заинтересовал меня такой концептуальный :) вопрос...
Есть система, построенная по принципу 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 я имел в виду как отрицательный момент хождения на сервер через один коннект

softwarer Роман ДынникА по-моему автор не сказал что эксклюзивная блокировка на чтение требуется.
А по-моему, сказал:

надо тормозить один поток, пока с кешем работает другой.
И позже подтвердил.

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

Думаю внутри sqlservr.exe выполняется N потоков, которые теми-же механизмами (синхронизацией потоков) обращаются к общим ресурсам
ну типа пула планов запросов. Насчет долгого запроса - выигрыш от небольшой задержки от синхронизации при обращении к пулу планов запросов оказывается существеннее чем заново строить план.

softwarer Alex S> А вот это напрягло бы меня куда больше, нежели какие-то кэши.

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

Ну значит оставим по одному соединению на поток. :)
Правда осталось не понятным что изначально напрягло....

softwarer Alex SСчитайте мой сервер приложений аналогом оракловой службы TNSListener (чем она не третье звено в _классической_ клиент-серверной архитектуре? :) )
Всем. Не стоит щеголять грамотностью там, где ни фига не разбираетесь.

Впрочем, можете провести эксперимент. Запустите программу, вырубите TNS Listener и увидите, что программа продолжает нормально работать. Когда добьетесь такого же результата от своего аппсервера, приходите.
Ну хорошо, неудачный пример, не надо злиться :) Возьмем для примера
SSNETLIB.DLL от MSSQL. Честно говоря, у меня уже нет уверенности, что если ее тоже как-нибудь вырубить, то подключения по сокетам к серверу не остануться :) Но суть я думаю понятна. Мне нужен этот "драйвер" - он выполняет те задачи, про которые я написал. SSNETLIB.DLL выполняет свои задачи, мой СП - свои. В чем ущербность подхода?

Petro123 mcureenab Petro123 Роман Дынник авторВообщето кэш ради ускорения БД - глупость
Ну я бы так не сказал...
..... повторно не запрашивать данные из БД если они не были изменены.
интересно, как ты ЭТО узнаешь?

ЭТО не надо узнавать, если все изменения объектов проходят через кэш.
Более мягкий вариант -- блокировка записи в БД, соответсвующей объекту в кэше на то время, пока объект закреплён в кэше.
Перед закреплением объекта в кэше можно повторно загрузить его из БД и заблокировать запись, можно этого не делать, если мы уверены, что запись не изменялась или нам полная когерентность кэша не важна.
слишком тяжёлое решение с сомнительным результатом ( эффективностью ).
Это вам не страницы читать (сектора с HDD).
Да и подмена обязанностей сервера (не надо его жалеть - он же СЕРВЕР).

Удачи Аффтару!

Ну зачем блокировать-то ! ??? Можно узнать по дате изменения: если в кеше она равна той что в базе - можно использовать кеш, если более новая - нужно перечитать этот объект в кеше. Дату читать быстрее чем весь объект целиком.

Впрочем в моем случае еще проще: шаблоны отчетов и т.п. меняются в базе только при смене версии. Процедура смены версии выставлет флаг в базе (дату/время версии) которую проверяют другие потоки в нужные моменты и, если она отличается от ранее считанной - чистят кеш и перечитывают дату версии.

mcureenab Alex SНу зачем блокировать-то ! ??? Можно узнать по дате изменения: если в кеше она равна той что в базе - можно использовать кеш, если более новая - нужно перечитать этот объект в кеше. Дату читать быстрее чем весь объект целиком.

Блокировать нужно для того, чтобы при сохранении кэшированного объекта не затереть изменения сделанные кем то другим. Если объект используется только для чтения, то блокировать скорее всего не нужно, но тогда и закреплять объект в кэше тоже не нужно.
Читать дату не на много быстрее чем объект, в прочем если дата (а ещё лучше некий серийный номер, который инкрементируеся при каждом изменении записи) не изменилась, то можно немного сэкономить на трафике. На системном уровне я таких решений не встречал. Обычно в кэш просто считывается объект из БД без всяких проверок.
Нет!!, блокировать не нужно, чтобы не затереть изменения, сделанные кем-то другим. Чтобы не затереть нужно выполнять update при изменении по двум ключам: ID изменяемого объекта и _ДАТЕ_ПОСЛЕДНЕГО_ИЗМЕНЕНИЯ_ изменяемого объекта.В качестве значения даты передавать то, которое считано в момент чтения объекта. Если количество затронутых оператором update записей (RowsAffected) равен 1, то обьект благополучно изменился так как даты в таблице и параметре update совпали (Т.Е. объект никто на поменял пока мы с ним работали) Если равен 0 - то объект был изменен, но в этом случае мы ничего и не затерли. Дальше зависит от логики.

Разумеется вместо даты последнего изменения можно использовать GUID - просто он имхо несет меньше "смысловой нагрузки" (банально узнать когда было последнее изменение).Да и байт в нем больше - поиск медленнее ;)

Чиать дату намного быстрее чем объект. Например, шаблон отчета может весить до 3~5 Mb, кроме того чтение BLOB (у меня шаблоны хранятся BLOB полях) подразумевает дополнительные низкоуровневые операции.

Кроме того, кроме непосредственно чтения происходит меппинг содержимого таблиц в иерархии классов (в случаях, более сложных чем шаблон отчетов) Выгоднее один раз это проделать и положить экземпляр "заполненного" класса в кеш. При выборе из кеша происходит простое копирование свойств экземпляра класса в другой экземпляр (Assign).

ВМоисеев>Alex S
>Заинтересовал меня такой концептуальный :) вопрос...

Продолжаю искать (уточнять) решение задачи, почти аналогичной Вашей. Текущие (на то время) результаты опубликованы здесь:
http://www.gotdotnet.ru/LearnDotNet/NETFramework/223738.aspx
Подключаю удаленных клиентов к пулу СП.

С уважением, Владимир.
спасибо, обязательно посмотрю

Перечитал с утра ветку. Хочу ответить, уточнить...

Petro123ЗЫ. Чем шаблоны отчётов лучше остальных данных получаемых с сервера - непонятно.

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

Шаблоны отчетов, описания атрибутов, форм и т.п. являются чем-то вроде объектов конфигурирования функционала. Ну т.е. в классическом приложении они должны были бы быть "вкомпиленными" в exe, но у меня лежат в базе. Плюсы такого подхода:
1) смена версии = update и insert по базе
2) неограниченное расширение функционала при неизменности exe
3) оперативность внесения изменений
Минус: требуется время на выборку и интерпретацию информации из базы.
С помощью кеширования я минимализирую "минус" :)

softwarer
С каких это пор чтение из кэша стало требовать эксклюзивной блокировки, да еще и на уровне кэша в целом?

У меня сейчас закрались подозрения, что я не достаточно точно объяснил, что я собирался синхронизировать (блокировать).

Не операции чтения БД, совсем нет.
Я говорю про синхронизацию при доступе к объекту класса "глобальный кеш" из потоков (нитей, Thread) _внутри_ exe сервера приложений.

Ну типа есть такой класс:


и есть экземпляр этого класса ОДИН на несколько потоков.


Любой поток будет вынужден войти в критическую секцию, для того чтобы вызвать метод GetItem (найти информацию в кеше). Вы скажете, что операцию чтения в данном случае не надо синхронизировать? Но ведь даже при поиске меняется содержимое памяти, например по указателю переменной счетчика цикла, когда я буду перебирать объекты в списке FList для того чтобы найти нужный. А если меняется содержимое памяти, то такой код нужно защищать от угрозы изменения ее одновременно из двух потоков.

Сейчас у меня _каждый_ поток имеет свой экземпляр класса TGlobalCache, и если несколько потоков работают с одной конфигурацией (а-ля одной БД), то велика вероятность что у каждого потока в кеше есть объекты, присутствующие в кеше других потоков - а значит в общей памяти приложения.

softwarer Alex SУ меня сейчас закрались подозрения, что я не достаточно точно объяснил, что я собирался синхронизировать (блокировать).
Не беспокойтесь, сейчас Вы объяснили в точности то же, на что я отвечал. И девятнадцать часов назад Колобок уже рассказал Вам, как это следует делать.

Alex SЛюбой поток будет вынужден войти в критическую секцию, для того чтобы вызвать метод GetItem
Глупость, этого совершенно не требуется. Другой вопрос, что при описываемых Вами параметрах использования кэша такой грубой синхронизации вполне может хватить без заметного ущерба эффективности - если поиск объекта в кэше быстрый.

Alex SВы скажете, что операцию чтения в данном случае не надо синхронизировать?
Я скажу, что если бы принимал у Вас экзамен, поставил бы Вам тройку. Точнее, благодаря вот этому:

Alex SНо ведь даже при поиске меняется содержимое памяти, например по указателю переменной счетчика цикла,
.. я бы выбрал базовой оценкой двойку, но за желание думать и таки знание, что такое критические секции добавил бы балл.
Что за пафосный тон? Форум существует для того, чтобы принимать экзамены или помочь разобраться в проблеме?

kolobok0
2) синхронизация требуется для доступа к данным, которые могут быть изменены. Например кол-во элементов в списке, сами данные в списке, некие глобальные данные и прочая муть... На чтение, если объект кэша существует -А я про что ?
Alex SЛюбой поток будет вынужден войти в критическую секцию, для того чтобы вызвать метод GetItem


Сам разберусь.

Petro123вы не задумывались, где остальные смертные хранять "тяжёлые отчёты"? Причём с обновлением версии на сервере? И без всякого промежуточного сервера, кэша, блокирования, ...... зарплаты разработчика/программиста/внедренца/обслуженца.
Боюсь предположить: там-же - в базе ? Причем тут моё желание ускорить процесс "предоставления" их "клиенту"? Нет, не поймите меня неправильно: не сделать так же быстро как у других смертных, а сделать _быстрее_ чем у них. Я с промежуточным сервером думаю что могу это сделать. Могут ли остальные смертные - не знаю. И внедренцы/обслуженцы тут при чем?
softwarer
Вы - не про то. Колобок - про синхронизацию, Вы - про синхронизацию критической секцией. Разницу между этими вариантами легко увидеть на примере стандартного класса дельфы TMultiReadExclusiveWriteSynchronizer.
Да, разобрался. Спасибо

-=*ShamaN*=-Пардон, не в тему что-то рубанул
глобальный кеш делать есть смысл

выглядеть будет примерно так:

Похоже принцип тот-же. Ну то-есть блокировать только запись.
Пришлось кое-что переделать/упростить, но сделал.
Спасибо

Petro123 Alex S не сделать так же быстро как у других смертных, а сделать _быстрее_ чем у них.
Я с промежуточным сервером думаю что могу это сделать. Могут ли остальные смертные - не знаю. И внедренцы/обслуженцы тут при чем?
для этого обычно пишут в таком виде:

авторПроблема: AAAAAAAAAA

Решение № N (для 2-х звенки): BBBBBBBBBBBBB

Недостаток стандартного подхода: Например при 2-х звенке отчёт размером N килобайт обновляется раз в месяц за время N-сек. ОООчень долго.

Предлагаемый подход на основе 3-х звенки: CCCCCCCCCCCCCC
это IMHO стандартный подход, и его можно сразу в FAQ при желании.

А так - велосипеды и неконкретный трёп IMHO

Да при чем тут 3-звенка ???? Аналогичный кеш у меня есть и в клиент-серверном проекте.
Его необходимость вытекает из того, что шаблоны, описания классов, формы редактирования документов(DFM) массивы перечислимых типов и т.п. хранятся в БАЗЕ, а не вшиты в EXE.
Другими словами я вынес "функциональные описания" из exe в базу и получил от этого много хорошего - перечеслять не буду - думаю понятно.
При этом получил немного плохого: скорость предоставления этой информации снизилась. Теперь я с помощью кеша нивелирую эту задержку.

На 3-х звенке я могу просто организовать ОБЩИЙ кеш. На 2-х звенке у меня у каждого клиента он свой.

Вообще не знаю что вы называете конкретикой. Это?
авторПроблема: AAAAAAAAAA

Решение № N (для 2-х звенки): BBBBBBBBBBBBB

Недостаток стандартного подхода: Например при 2-х звенке отчёт размером N килобайт обновляется раз в месяц за время N-сек. ОООчень долго.

Предлагаемый подход на основе 3-х звенки: CCCCCCCCCCCCCC

Я приводил свои аргументы в этой ветке. Имхо вполне конкретные.