Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Вопрос шарам Tomcata & J2EE

554
02 ноября 2005 года
Zhilin Mike
159 / / 11.02.2003
Столкнулся с такой проблемой. Я считываю данные с базы данных из сервлетов. Поэтому происходит постоянно подсоединение к базе и совершение запросов.

Причем некоторые запросы происходят очень часто и хотелось бы хранить некоторые данные в каком нибудь постоянном кэше при многократном обращение к сервлету.

Есть ли такая легковесная технология, отличная от enterprise бинов, которая позволила бы мне так просто сохранять данные запросов. А?!
14K
09 ноября 2005 года
Ruslan K.
3 / / 09.11.2005
Если по-простому, то я бы не заморачиваясь сделал WeakHashMap, где в качестве ключей использовал бы какую-либо комбинацию, однозначно определяющую необходимую выборку данных среди прочих возможных выборок (коллекцию ресторанов среди коллекций юзеров, магазинов и т.п.), а в качестве значений, сопоставленных ключам, - коллекции данных. Всю эту баланду сохранил бы в сессии и при попытке обращения к ней проверял бы, есть ли в кэше значение, соответствующее ключу. Если нет, то нужно делать запрос.

Основные недостатки такого подхода:

1) Дополнительный расход памяти сервера. Насколько я понимаю эту самую матчасть, память является более ценным ресурсом, чем процессорное время, требуемое для осуществления запроса. Тем более, если база данных использует различные оптимизации по скорости. К примеру, MySQL это дело очень любит:)

2) Если ты используешь данные из кэша, ты используешь устаревшие данные, не всегда соответствующие тому, что есть в базе данных. Поэтому нужно быть аккуратным. Можно наплодить косяков вроде такого (и ещё много-много других): к примеру, у тебя есть таблица (X,Y) и бизнес-правило:

(X,Y)=([A,B],[{[a,b,c], если X=A},{[d,e,f], если X=B}]).

Далее, предположим, в сессии пользователя Q ты сохранил в кэше результат запроса

SELECT * FROM XYtable;

Далее, пусть пользователь P меняет несколько значений X с A на B и меняет соответствующие им Y, к примеру, с a на d.

Далее, пользователь Q, к примеру, выставляет для всех Y, у которых X = A, значение b. Если ты используешь для проверки корректности подобного преобразования данные из кэша, то значения b будут также выставлены и для тех нескольких Y, которые уже соответствуют X = B. Таким образом, ты получишь противоречие в данных, чреватое дальнейшими косяками.

Кроме того, даже если ты правильно проведёшь проверку (т.е. засунешь проверку в транзакцию и осуществишь её по актуальным, а не кэшированным данным) и не допустишь противоречия в сохраняемых данных, тебе придётся каким-либо образом сказать пользователю Q, что он не может осуществить желаемое изменение, потому что данные уже малость не те, что он видит. Это вполне реальная ситуация и без кэширования, но вероятность подобного отказа возрастает пропорционально времени кэширования данных.
14K
17 ноября 2005 года
Ruslan K.
3 / / 09.11.2005
А ещё можешь использовать Pool соединений. Тогда не придётся каждый раз коннектиться к БД.
Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог