1
Скажите кэш Quries в хибернейте представляет из себя кэш запросов в которые потом подставляются переменные (иммется ввиду схожая модель с кэшем ораклЫ)или кэш содержит просто стринги уже с подставленными значениями, которые потом вызываются и уходят в базу как просто String. (Подозреваю, что реализовано именно первое). Но хотелось бы знать наверняка.
2
Я с тюнингом хибера никогда не занимался. Существуют какие-либо ресурсы по этому делу? А то в доке на оф сайте сказано в общем и ничего подробного. Хотелось бы ознакомиться чтобы знать хоть откуда ноги растут.
------------------------
Использую EhCacheProvider. +/- у сего продукта не знаю. Если есть более предпочтительные продукты хотелось бы получить ссылку для ознакомления с таковыми.
Alexander3 wrote: > Скажите кэш Quries в хибернейте представляет из себя кэш запросов в > которые потом подставляются переменные (иммется ввиду схожая модель с > кэшем ораклЫ)или кэш содержит просто стринги уже с подставленными > значениями, которые потом вызываются и уходят в базу как просто String. > (Подозреваю, что реализовано именно первое). Но хотелось бы знать наверняка.
Ни то, ни другое.
Кэш запросов — это кэш результатов запросов Он
сбрасывается, когда меняется одна из таблиц, входящих в запрос.
Сами запросы Hibernate умеет заранее готовить (prepare), при этом ни о
каком подстановке строк речи не идет — Hibernate такой фигней не
занимается вообще.
Здравствуйте, 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 используется только второй подход.
Он 
