Перечитал с утра ветку. Хочу ответить, уточнить...
Petro123ЗЫ. Чем шаблоны отчётов лучше остальных данных получаемых с сервера - непонятно.
1)Они редко меняются
2)Данные из таблицы, где записаны отчеты не используются нигде, кроме непосредственно считывания шаблона, перед запуском шаблона на выполнение.
Шаблоны отчетов, описания атрибутов, форм и т.п. являются чем-то вроде объектов конфигурирования функционала. Ну т.е. в классическом приложении они должны были бы быть "вкомпиленными" в exe, но у меня лежат в базе. Плюсы такого подхода:
1) смена версии = update и insert по базе
2) неограниченное расширение функционала при неизменности exe
3) оперативность внесения изменений
Минус: требуется время на выборку и интерпретацию информации из базы.
С помощью кеширования я минимализирую "минус" :)
softwarer
С каких это пор чтение из кэша стало требовать эксклюзивной блокировки, да еще и на уровне кэша в целом?
У меня сейчас закрались подозрения, что я не достаточно точно объяснил, что я собирался синхронизировать (блокировать).
Не операции чтения БД, совсем нет.
Я говорю про синхронизацию при доступе к объекту класса "глобальный кеш" из потоков (нитей, Thread) _внутри_ exe сервера приложений.
Ну типа есть такой класс:
1.
2.
3.
4.
5.
6.
7.
TGlobalCache=class(TObject)
private
FList:TObjectList; // список указателей на хранимые объекты
public
function GetItem(const aUID:string):TCachedInfo;//выбрать из кеша
procedure StoreItem(aInfo:TCachedInfo);//положить в кеш
...
end;
и есть экземпляр этого класса ОДИН на несколько потоков.
MyGlobalCache:TGlobalCache;
Любой поток будет вынужден войти в критическую секцию, для того чтобы вызвать метод GetItem (найти информацию в кеше). Вы скажете, что операцию чтения в данном случае не надо синхронизировать? Но ведь даже при поиске меняется содержимое памяти, например по указателю переменной счетчика цикла, когда я буду перебирать объекты в списке FList для того чтобы найти нужный. А если меняется содержимое памяти, то такой код нужно защищать от угрозы изменения ее одновременно из двух потоков.
Сейчас у меня _каждый_ поток имеет свой экземпляр класса TGlobalCache, и если несколько потоков работают с одной конфигурацией (а-ля одной БД), то велика вероятность что у каждого потока в кеше есть объекты, присутствующие в кеше других потоков - а значит в общей памяти приложения.
