«HIBERNATE CACHING»: разбор всех уровней на примере чужих ошибок
HTML-код
- Опубликовано: 26 сен 2024
- Тема: «HIBERNATE CACHING»: разбор всех уровней на примере чужих ошибок.
Уровень сложности: средний
Спикер: Игорь Дмитриев - технический менеджер SPD-Ukraine. Разработчик с 7 летним опытом, java-энтузиаст, выступает на ведущих конференциях: JUG.UA, JEEConf, Java Day, RockStar Night conferences и многих других ключевых IT мероприятиях.
Что ты узнаешь на воркшопе «Hibernate caching»:
1. Когда и зачем нужно его использовать (сконфигурируем его на одном из приложений с нуля);
2. Затронем все уровни кеширования: 1st level cache, 2nd level cache, query cache;
3. Игорь поделится своим опытом использования в продакшене и покажет много примеров;
4. Ты получишь бесценный опыт «чужих набитых шишек», и после доклада сможешь сам эффективно использовать кеш в своих проектах.
Презентация: drive.google.c...
Проект на GitHub: github.com/igo...
Другие выступления Игоря: • Мои выступления
Если хочешь начать карьеру Java разработчика, а платить только после трудоустройства, то познакомься с нашей программой подготовки: javalearn.online/
Следи за нами в социальных сетях:
Telegram: t.me/kata_academy
VK: kataaca...
________________________________________
Поступить в Kata: kata.academy/
Телефон: 8 (800) 350-32-96
Email: info@kata.academy
5:50 начало про кэш
отличный, подробный доклад
Всего 1 доклад? Делай ещё, всё ок 😀
Всем привет, по поводу первого уровня, на сколько я понял транзакции созданы только для изменения данных, а не для чтения, поэтому не совсем правильно читать в транзакции данные и потом ничего с ними не делать, но может я ошибаюсь?
Получается что кеш первого уровня работает только с транзакциями?
Но нет, я докапался до сути, необходимо над сущностями ставить аннотацию @Cacheable тогда для сущности будет работать кеш первого уровня, и при этом если я в application.yaml отключу кеш 2го уровня, все равно кеш 1го уровня будет работать и без транзакции
spring.jpa.properties.hibernate.cache.use_query_cache=true
spring.jpa.properties.hibernate.cache.use_second_level_cache=false
Кстати, так тоже работает, но тут возможно как раз работает только 2ой уровень:
spring.jpa.properties.hibernate.cache.use_query_cache=false
spring.jpa.properties.hibernate.cache.use_second_level_cache=true
Так не работает:
spring.jpa.properties.hibernate.cache.use_query_cache=false
spring.jpa.properties.hibernate.cache.use_second_level_cache=false
Вот весь код:
@Entity
@Table
@Cacheable
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE, region="account")
public class Account {
....
}
@Test
void testCache(){
Account account = entityManager.find(Account.class, 571);
Account account1 = entityManager.find(Account.class, 571);
Account account2 = entityManager.find(Account.class, 571);
}
1. Господи, благослови ютьюб с его длинными комментами. А то в кое какой соц сети приходится оставлять по 20 комментов в ряд, а они еще потом между собой шафляться.
2. Вроде транзакции не только для изменения данных используются. Если нужно чтобы 2 select запроса выполнились в 1 момент (и работали с одинаковыми данными), то транзакция вроде тоже нужна. Могу ошибаться.
Но перед этим видео я смотрел hibernate от Joker. Там он как раз рассказывал о проблеме, что было 2 select. Причем второй был select for update. И там у них была проблема, что между первым и вторым select происходили изменения данных в какой-то из транзакций
@@ziral0 Да, действительно, сейчас перепроверил в ChatGPT написали что требуется для согласованного чтения данных, но думаю что далеко не все случаи с этим связанны и должна быть алтернатива кешировать данные без транзакций)
В любом случае спасибо, буду знать этот ньюанс