Все неверно.
1. Query cache может быть только в кеше второго уровня, в специально отведенной для этого области.
2. Query cache хранит сопоставление [заропс] - [вытащенные айдишники], а не сами объекты.
3. При включенном кеше второго уровня и кеше запросов, повторный запрос не вызовет запроса к БД. Если же запрос все таки будет (например, вы принудительно его заставили это сделать), то существующие в кеше объекты будут перезаписаны (или не будут в зависимости от настроек), но никогда не будет ситуации, что в кеше есть больше одного объекта данного типа с одинаковым идентификатором.
4. С кешем первого уровня все точно так же: если вы 50 раз сделали селект записи по 5 одним и тем же сотрудникам, то на выходе у вас будет не 50*5 = 250 объектов в кеше, а 5.

Озвериня с хибером на вы ;) предположения.
читал, что в старых версиях, независимо от того, что сказал swenom - хранились не айдишники а объекты..
http://darren.oldag.net/2008/11/hibernate-query-cache-dirty-little_04.html Пожалуйста, цитата из официальной доки, глава 19.4 - http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.htm :
докаNote that the query cache does not cache the state of the actual entities in the result set; it caches only identifier values and results of value type . The query cache should always be used in conjunction with the second-level cache.

Вот еще хорошая статейка - http://www.javalobby.org/java/forums/t48846.html

ОзверинЯ читал офф доку.
https://hibernate.onjira.com/browse/HHH-3383 Ну только это не дока, а баг-трекер, в котором четко написано, что это баг, который уже пытались несколько раз исправить, но не добили.

Йуный джавистЪДа не нужен никакой кэш за пределами базы. Не мучайте себя.Ну вам не нужен, а людям, которые хоть что-то понимают в узких местах при работе с БД - еще как нужен.

Йуный джавистЪНу вам не нужен, а людям, которые хоть что-то понимают в узких местах при работе с БД - еще как нужен.

У людей, которые хоть что-то понимают в узких местах при работе с БД, все эти гибернейтовские кэши вызывают смех.
Вот, например, документация по самому популярному гибернейтовскому кэшу:
http://ehcache.org/documentation/get-started/consistency-options
We will walk through how a write is done and show that it is strongly consistent.
A thread in Ehcache A performs a write.
Before the write is done, a write lock is obtained from the Terracotta Server (storage system). The write lock is granted only after all read locks have been surrendered.

Один общий лок на весь кластер с кэшем. Точно такой же подход, как в 1С 7.Что плохого вы увидели в данном подходе? Как, на ваш взгляд, это можно исправить?

schwaЭта "фича" только у оракл есть, но ораклом базы не ограничены (хотя сама корпорация оракл так не считает, но это их проблемы).Более любопытно другое - Йуный джавистЪ почему-то противопоставляет кэш второго уровня хибера СУБД.
Йуный джавистЪНо все равно, получить несколько объектов такими, как они были на некоторый момент времени(read consistency), ни в одном из этих кэшей невозможно. Хотя в СУБД это есть с середины 80-х.Это как если бы я противопоставлял лопату тарелке каши

Йуный джавистЪСейчас такая фича есть даже у бесплатных MySQL и PostgreSQL. Я даже не могу назвать сервер, в котором бы ее не было.Остается понять какое отношение эта фича имеет к понятию "кеш".

Йуный джавистЪБолее любопытно другое - Йуный джавистЪ почему-то противопоставляет кэш второго уровня хибера СУБД.

Не противопоставляю, а сравниваю.
Кэш и СУБД одинаково являются транзакционными хранилищами данных. В них используюся одинаковые механизмы (локи, MVCC). Не вижу, почему их нельзя сравнивать.
Если мы используем кэш поверх СУБД, то транзакции у нас будут только такие, какие поддерживает кэш. Если СУБД поддерживает read consistency, а кэш нет, то связка СУБД и кэша не поддерживает read consistency.Ой ой ой, как же все неверно. Буквально наизнанку вывернуто.
Кеш не является транзакционным хранилищем данных. Кеш это просто временное хранилище данных, точка. Не надо ему приписывать то, для чего он не предназначен. Цель кеша - снизить количество обращений к некоему стороннему "дорогому" ресурсу. В случае Хибера - к СУБД, так как сериализация и передача по TCP это дорогая операция по сравнению с получению ранее вытащенного обекта их памяти JVM. Но, разумеется, как и всегда, кеш не является универсальным решением, ему присущи проблемы. Какие именно? Первая - повышенные требования к памяти, т.е. экономим на дорогом обращении к СУБД, но теряем в памяти. Вторая - кеш склонен протухать. Любой кеш любой технологии имеет это свойство. Поэтому, работая с кешем, мы за ускорение работы платим риском того, что в какой-то момент данные, с которыми мы работаем окажутся в неактуальном состоянии. Это абслоютно нормально, это ожидаемое поведение кеша.
Ну а транзакции - где вы в кеше транзакционность нашли? Кеш второго уровня как раз и предназначен для того, что бы быть вне транзакций