У вас есть два пути:
1) Нафигачить кэш руками. По сути, это будет обычный HashMap. Потом в ваших Дао добавить запись/чтение. Из плюсов - легковесно и полностью под вашим кнтролем. Минусы: надо писать код, плюс обязательно правильно разруливать синхронизацию апдейтов кэша и транзакций СУБД.
2) Взять стороннее решение. Например - hazelcast. Минусы - лишняя зависимость в проекте. Плюсы: все уже написано за вас, поддержка транзакций есть, включая J2EE транзакции, вам надо только интегрировать это в свой проект.

Что вам ближе - решайте сами.

Все ясно. Тогда ищите кэши, который вас удовлетворят. Можете отталкиваться от hazelcast для начала.

BlazkowiczЧем это лучше стандартной схемы. Если запись поменялась, дропаем из кеша и перечитываем из базы, если её нет в кеше?
Зачем делать изменения в кеше. Если дропнуть проще. А чтение из базы в кеш уже реализовано?Ну скажем прямо, дроп из кэша это не стандартная схема. А вот write-thorough, про который говорит автор - вполне себе стандартное решение.
Плюсы ее использования очевидны:
1) Уменьшаем нагрузку на базу. Ведь если таблицу активно читают, то каждый cache miss может вылитьс даже не в одно, а в несколько чтений.
2) Как вы будете разруливать ситуацию, когда кто-то пытается прочитать несуществующее значение? Например, когда ридеру нужен ключ A, которого никогда не было базе? Вам для этого придется лезть в БД. А в случае write-through с полностью прогретым на старте кэшем (а полный прогрев - это условие автора), у вас кэш всегда консистентен с СУБД, то есть вы можете гарантированно сказать, каких ключей нет не обращаюсь в СУБД.
3) Наконец, write-through подход позволяет полностью разделить читателей и писателей. Поэтому здесь концептуально подойдет банальный ReadWriteLock (именно концептульно, как идея), когда ридеры гарантирвоанно друг друга не блокируют, им никогда не нужен эксклюзивный доступ, а у врайтера есть экслюзивный доступ, если нужно обновить какой-то ключ. А в вашем случае ридерам время от времени будет требоваться брать эксклюзивный лок на ключе, что усложнит логику и увеличит контеншн, ибо надо брать в расчет следующую ситуацию:
WRITER 1: записал К = 1, удалил ключ из кэша
READER 1: прочитал К, увидел K = 1
WRITER 1: записал K = 2
READER 2: прочитал K, увидел K = 2
READER 2: положил K = 2 в кэш
READER 1: положил K = 1 в кэш

Все, приехали, race condition, в СУБД у нас 2, а в кэше 1. Поэтому удаление ключей из кэше при обновлении - нифига не простое решение.

Так что write-through здесь выигрывает по всем параметрам, имею соизмеримую сложность имплементации.

Hazelcast, Infinispan - там есть все, что нужно.

Relic HunterА зачем, что-то кешировать? Этим занимается база данных. Или вы обращаетесь к ней через Интернет?Любое обращение к СУБД - это как минимум сериализация-десериализация, а как максимум - еще и TCP запрос(ы) на удаленный компьютер. Так что никакие кэши на стороне СУБД здесь не спасут.

Relic HunterВы уже определили, что СУБД или сеть у вас узкое место? Если да, то в первую очередь нужно дергать админстраторов сетей и СУБД этих самых, а не перекладывать их головную боль на свою.Коллега, вы можете добиться самого оптимального в мире плана для конкретного запроса на конкретной СУБД, но при этом любой вызов этого запроса из другого процесса будет в десятки, если не сотни раз медленнее, чем просто взять объект из кэша того же процесса. На то есть объективные причины: сериализация и RPC.
Почему автор пришел к необходимости кэширования - вопрос к нему. Но в любом случае, я думаю, вы не будете спорить с тем, что взять готовый объект из адресного пространства того же процесса во много раз быстрее, чем получить его из другого процесса.

just_vladimir ,
Откуда вы взяли такие цифры? Разница может какой-угодно. Может быть, там СУБД и приложение на одной машине, общаются через shared memory, запросы маленькие и хорошо заоптимизированные, и т.п. В этом случае разница во времени будет не существенной.
А может быть СУБД и приложение разделены медленной сетью, запросы тяжелые, на апдейтах сидят пессимистичные блокировки, а пул соединений ограничен и не может быть расширен, а потоков, тебующих свой коннект в разы больше, чем коннектов в пуле. Тогда разница по сравнению с закешированным вариантом будет измеряться не то, что миллисекундами, а минутами, а то и десятками минут. Поэтому, не зная всех деталей, мы можем только гадать, что именно побудило автора прийти к кэшированию.

Но сама по себе идея кэширования является естественной и нормальной практикой. Тот же Хибер весь пронизан кэшами. Более того, учитывая то, что автору не требуется никаких серьезных заморочек вроде партицирования/реплицирования/write-behind и прочей фигни, нет никаких проблем взять какой-нибудь Infinispan, и запилить его в свой проект за несколько часов. Поэтому нет особых причин лезть в душу автору, и выпытывать у него действительно ли ему нужен кэш.