softwarerdph3Так что иногда имеет смысл делать все-таки ручное кэширование.
Не спорю. Я вовсе не против кэширования; я против... того позиционирования, которое видится у топикстартера. Если я правильно понял его отношение, то в итоге собственного написания подсистемы кэширования у него получится специализированная in-memory СУБД, примерно так.

Да я понимаю, что ты это и так все прекрасно знаешь )

я против... того позиционирования, которое видится у топикстартера. Если я правильно понял его отношение, то в итоге собственного написания подсистемы кэширования у него получится специализированная in-memory СУБД, примерно так.
Угу. При том, что памяти и так мало, а запросы редкие - в результате проблем будет у топикстартера только больше. Особенно когда БД в память не поместиться.

SERG1257Чисто из любопытства как кэш узнает что данные поменялись другой сессией и его (кэш) надо бы освежить
Если у нас не кластер и работа с БД делается через общий код, то в чем проблема? Тот код, что изменил данные - заодно и инвалидировал кэш (общий на виртуальную машину). В Hibernate, подозреваю, это делается вполне себе автоматически.

А вообще, для подобных задач есть минимум три принципиально разные стратегии ;)

SERG1257
Первый - это просто таймер - по прошествии некоторого времени обновляемся
Второй - это регистрируемся в базе как подписчик некоего события и при изменении к-л. поля триггер сообщает подписчикам (асинхронно), что данный объект изменен
Третий - триггер вставляет запись в change log и подписчики регулярно просматривают свежие сообщения на предмет не задеты ли их закэшированные данные.

Если что не учел - напомните.

Ну, я имел в виду немножко другое.

Первый вариант я вообще не рекомендую, уж очень дорогой.
Второй - крайне специфичен для конкретного сервера БД, сильно зависит от версии драйверов, потенциально глюкавый. Хотя если связываться не с БД, а с другим app-сервером, то получится классический push (синхронный или асинхронный - это уже детали реализации)
Третий - это одна из стандартных реализаций pull (вариантов там кучка).
И есть еще checkVersion - это когда у каждой строки (или, лучше, у каждого хранящегося в БД объекта) есть version (с инкрементом на каждое изменение) и при получении данных из кэша проверяется версия (один select по упорядоченному индексу - т.е. мгновенно) и если версии в кэше и в БД не совпали - то инвалидируем. Если совпали - то и хорошо. Впрочем, можно рассматривать это как вариант pull стратегии.

По опыту - обычно в проектах требуется как минимум две разные стратегии :)