Alexander3 wrote:
> Скажите кэш Quries в хибернейте представляет из себя кэш запросов в
> которые потом подставляются переменные (иммется ввиду схожая модель с
> кэшем ораклЫ)или кэш содержит просто стринги уже с подставленными
> значениями, которые потом вызываются и уходят в базу как просто String.
> (Подозреваю, что реализовано именно первое). Но хотелось бы знать наверняка.
Ни то, ни другое.

Кэш запросов — это кэш результатов запросов Он
сбрасывается, когда меняется одна из таблиц, входящих в запрос.

Сами запросы Hibernate умеет заранее готовить (prepare), при этом ни о
каком подстановке строк речи не идет — Hibernate такой фигней не
занимается вообще.

Cache in hibernate

Hi,

1
Скажите кэш Quries в хибернейте представляет из себя кэш запросов в которые потом подставляются переменные (иммется ввиду схожая модель с кэшем ораклЫ)или кэш содержит просто стринги уже с подставленными значениями, которые потом вызываются и уходят в базу как просто String. (Подозреваю, что реализовано именно первое). Но хотелось бы знать наверняка.

2
Я с тюнингом хибера никогда не занимался. Существуют какие-либо ресурсы по этому делу? А то в доке на оф сайте сказано в общем и ничего подробного. Хотелось бы ознакомиться чтобы знать хоть откуда ноги растут.

------------------------
Использую EhCacheProvider. +/- у сего продукта не знаю. Если есть более предпочтительные продукты хотелось бы получить ссылку для ознакомления с таковыми.

Заранее всем спасибо!

Здравствуйте, Cyberax, Вы писали:

C>Сами запросы Hibernate умеет заранее готовить (prepare), при этом ни о
C>каком подстановке строк речи не идет — Hibernate такой фигней не
C>занимается вообще.

Следует также сказать, что тратить ресурсы Java на кеширование скорей всего не имеет смысла, если коннект до базы быстрый (локальный) и база эта — ORACLE (хотя и другие тоже небось). У ORACLE специальный сегмент под кеш выделен, выборка оттуда быстрей и у него больше возможностей отслеживать изменения в таблицах.

Здравствуйте, aefimov, Вы писали:

C>>Сами запросы Hibernate умеет заранее готовить (prepare), при этом ни о
C>>каком подстановке строк речи не идет — Hibernate такой фигней не
C>>занимается вообще.
A>Следует также сказать, что тратить ресурсы Java на кеширование скорей всего не имеет смысла, если коннект до базы быстрый (локальный) и база эта — ORACLE (хотя и другие тоже небось).
Зависит от условий. У меня кэш запросов работает примерно в 10 раз быстрее простого "SELECT 1" из базы — все-таки не нужно делать сетевой вызов с переключение контекста и прочим.

Здравствуйте, Cyberax, Вы писали:

C>Зависит от условий. У меня кэш запросов работает примерно в 10 раз быстрее простого "SELECT 1" из базы — все-таки не нужно делать сетевой вызов с переключение контекста и прочим.

Одно дело select 1 from dual, а другое дело трехэтажный select, выгребающий туеву кучу данных. Хранить это в Java кэше не имеет смысла. Во первых GC одуреет, во вторых для кластера это особенно прикольно.

Здравствуйте, aefimov, Вы писали:

C>>Зависит от условий. У меня кэш запросов работает примерно в 10 раз быстрее простого "SELECT 1" из базы — все-таки не нужно делать сетевой вызов с переключение контекста и прочим.
A>Одно дело select 1 from dual, а другое дело трехэтажный select, выгребающий туеву кучу данных. Хранить это в Java кэше не имеет смысла.
Естественно, такие запрос и в кэше Оракула, скорее всего, нет смысла хранить.

A>Во первых GC одуреет, во вторых для кластера это особенно прикольно.
Не так все плохо — Tangasol спасает

Имеется ввиду тот факт, что hibernate генерит конечные запросы в run-time.
Так вот возникает вопрос, что такая генерация происходит каждый раз при вызове метода? Или все таки генерация происходит ровно один раз, сохраняется в кэш или куда-то еще а потом вызывается уже говтовый запрос с подставленными туда bind variables. Если же запрос меняется, то происходит обновление. запроса.

Спасибо.

Здравствуйте, Alexander3, Вы писали:

A>Имеется ввиду тот факт, что hibernate генерит конечные запросы в run-time.
A>Так вот возникает вопрос, что такая генерация происходит каждый раз при вызове метода? Или все таки генерация происходит ровно один раз, сохраняется в кэш или куда-то еще а потом вызывается уже говтовый запрос с подставленными туда bind variables. Если же запрос меняется, то происходит обновление. запроса.
Да, запросы лишний раз не создаются там, где это возможно.

Но у вас, видимо, какие-то непонятки — в текст запроса при binding'е ничего не вставляется. Binding переменных делается на уровне JDBC-драйвера (а он, скорее всего, будет делегировать это двжику БД).

Здравствуйте, Cyberax, Вы писали:

C>Но у вас, видимо, какие-то непонятки — в текст запроса при binding'е ничего не вставляется. Binding переменных делается на уровне JDBC-драйвера (а он, скорее всего, будет делегировать это двжику БД).

Под binding variables я понимаю сами значения которые непосредственно подстанавливаются

потому что для ораклЫ есть разница между

select * from AAA a where a.id=10

и

select * from AAA a where a.Id=:id_value

(где id_value =10)
в первом случае будет парсинг. компайлинг и пр (что еще оракла делает для нового запроса) для кадого нового id,
а во втором случае при новом значении сам запрос потянется из кэша ораклы а вот значение подставится уже нужное

Alexander3 wrote:
> в первом случае будет парсинг. компайлинг и пр (что еще оракла делает
> для нового запроса) для кадого нового id,
> а во втором случае при новом значении сам запрос потянется из кэша
> ораклы а вот значение подставится уже нужное
В Hibernate используется только второй подход.