Вопрос шарам Tomcata & J2EE
Столкнулся с такой проблемой. Я считываю данные с базы данных из сервлетов. Поэтому происходит постоянно подсоединение к базе и совершение запросов.
Причем некоторые запросы происходят очень часто и хотелось бы хранить некоторые данные в каком нибудь постоянном кэше при многократном обращение к сервлету.
Есть ли такая легковесная технология, отличная от enterprise бинов, которая позволила бы мне так просто сохранять данные запросов. А?!
Причем некоторые запросы происходят очень часто и хотелось бы хранить некоторые данные в каком нибудь постоянном кэше при многократном обращение к сервлету.
Есть ли такая легковесная технология, отличная от enterprise бинов, которая позволила бы мне так просто сохранять данные запросов. А?!
Если по-простому, то я бы не заморачиваясь сделал 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, что он не может осуществить желаемое изменение, потому что данные уже малость не те, что он видит. Это вполне реальная ситуация и без кэширования, но вероятность подобного отказа возрастает пропорционально времени кэширования данных.
Основные недостатки такого подхода:
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, что он не может осуществить желаемое изменение, потому что данные уже малость не те, что он видит. Это вполне реальная ситуация и без кэширования, но вероятность подобного отказа возрастает пропорционально времени кэширования данных.
А ещё можешь использовать Pool соединений. Тогда не придётся каждый раз коннектиться к БД.