Skip to content

kaarlych/HibernateExamples

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

54 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Zapytania na bazie danych:

     JPQL - specyfikacja JPA definiujaca jezyk zapytan, ktora jest mieszanka SQL i obiektow
     - Jakarta Persistance Query Language
     - jezyk bardzo podobny do sql ale bedziemy operowali na obiektach
     - HQL - Hibernate Query Language - podzbior JPQL
     - wada HQL jest to ze jest podobny do SQL i ludzie czesto myla go z SQL
     - HQL ma wlasna gramatyke w postaci Stringa
     - HQL nie sluzy do modyfikacji bazy danych, sluzy tylko do CRUDow
     - sa tlumaczone przez Hibernate to tradycyjnych SQLek
     - HQL pracuje na podstawie klas i ich wlasciwosci a nie na podstawie tabel i kolumn jak SQL



     Criteria API -
     Native Query
     Stored Procedures

     DTO - Data Transfer objects

Mechanizm paginacji

  • ograniczenie ilosci wynikow zapytania

Named queries

  • pomaga w grupowaniu zapytan hql w jednym miejscu
  • w efekcie mamy czystszy kod
  • adnotacja @NamedQuery

FetchMode

  • ustawienie tego parametru ma wplyw na wydajnosc aplikacji
  • mechanizm z Hibernate
  • okresla jak hibernate ma dociagnac encje podprzedne

n+1 problem

  • najczesciej pojawia sie w relacji one-to-many
  • polega na tym ze hibernate pobiera dane z bazy w n+1 zapytaniach
  • n+1 zapytan - 1 zapytanie na glowna encje i n zapytan na encje podrzedne
  • rozwiazanie: fetchmode, fetch, batchsize

set vs list w mapowaniach

  • persistenceBag - domyslnie ustawione dla list
  • set nie przechowuje duplikatow - list przechowuje duplikaty
  • persistanceBag - nie zachowuje kolejnosci mimo ze jest implementacja listy
  • set zajmuje wiecej pamieci od listy
  • hibernetowa implementacja seta jest persistenceSet
  • stosujac set w hibernacie trzeba pamietac o equals i hashcode

Eguals() and Hashcode()

Sortowanie

  • order by w hqlce
  • @OrderBy("nazwa_kolumny")
  • najlepiej sortowac dane na poziomie bazy danych (wydajnosc) i nie zawracac tym sobie glowy w javie
  • mapoowanie wyjatkow:

Native Query

  • natywne zapytania sql - wlasciwe sql dla danej bazy danych
  • mechanizm ktory pozwala na wykonanie zwyklej slqki w hibernate

Criteria API

  • obiekt Criteria Query na ktorym bedziemy okreslali rozne filtry
  • Od Hibernate 5.x Criteria API jest zdeprecjonowane
  • Tworcy Hibernate zdecydowali na tworzenie wlasnego Criteria API
  • Zapytania zorientowane obiektowo

Connection Pool

  • cache of database connections maintained so that the connections can be reused when required
  • HikariCP - najlepszy connection pool
  • chodzi o to zeby nie otwierac co chwila nowego polaczenia do bazy danych tylko jest pewna pula
  • tworzymy polaczenie i wrzucamy do worka i potem wyciagamy je z worka
  • polaczen do bazy danych moze byc wiecej niz jedno - zaleznie od ilosci watkow
  • troche podobnie jak Stringpool
  • oszczednosc czasu i zasobow

Cachowanie w Hibernate

  • first level cache & second level cache
  • cache - hardware or software component that stores data so that future requests for that data can be served faster
  • cache jest po to zeby nie ladowac danych z bazy danych za kazdym razem
  • first level cache jest wlaczony domyslne w hibernate -nie trzeba nic robic
  • nie da sie go wylaczyc - jest to cache na poziomie sesji
  • second level cache - cache na poziomie aplikacji
  • kazdy obiekt session na swoj first level cache
  • 1LC jest na sztywno zwiazany z session

-> First Level Cache

  • jest domyslnie wlaczony i nie mozna go wylaczyc
  • obejmuje jedna sesje po zamknieciu sesji obiekty znikaja z pamieci
  • Hibernate nie pozwala na zapisanie obiektu wiecej niz jeden raz
  • jezeli w tej samej sesji pytamy 2 razy o ten sam obiekt to Hibernate zaladuje encje z first level cache
  • caly 1LC mozna usunac przy uzyciu metody clear() na obiekcie session
  • evic() - usuwa obiekt z 1LC
  • clear() - usuwa caly 1LC

-> Second Level Cache

  • cache na poziomie aplikacji
  • cache jest wspoldzielony przez wszystkie sesje
  • mozna go wylaczyc
  • cache jest zalezny od dostawcy
  • interfejs RegionFactory - java specyfikuje interfejsy ale trzeba go zaimplementowac
  • jednym z dostawcow jest ehcache
  • cache mozna konfigurowac w pliku xml
  • adnotacje @Cache i @Cachable - Enable Selective - domyslnie zalecana
  • Disable selective - @Cache(usage = CacheConcurrencyStrategy.NONE)

-> Locki bazodanowe

  • database lock/database concurrency control
  • locki w bazie danych - mechanizm blokowania wierszy w bazie danych
  • locki w hibernate - mechanizm blokowania obiektow w hibernate
  • locki w hibernate sa zalezne od dostawcy
  • tematyka zwiazana z concurrency
  • concurrency - wspolbieznosc - wielowatkowosc
  • optimistic locking - optymistyczne blokowanie
  • pessimistic locking - pesymistyczne blokowanie
  • lock bazodanowy - mechanizm pozwalajacy na blokowanie danych w bazie danych
  • kazdy uzytkownik strony internetowej ma swoja sesje bazodanowa
  • jezeli wielu uzytkownikow dokonuje zmiany na danych to tylko jeden uzytkownik bedzie w stanie je zmienic
  • hibernate obsluguje dwa rodzaje lockingu - optimistic oraz pessimistic

-> Optimistic Locking

  • zaklada ze konflikty sa mozliwe ale beda wystepowac rzadko
  • wersjonowanie - dodanie kolumny wersji do tabeli
  • wersjonowanie jest domyslnie wylaczone
  • wersjonowanie jest wlaczone przez adnotacje @Version
  • tutaj jest numerek o weryfikacji czy ktos juz przed nami nie zmienil danych

-> Pessimistic Locking

  • zaklada ze konflikty sa mozliwe i beda wystepowac czesto
  • zablokowanie zasobu na wylacznosc
  • blokowanie dostepu do danych drugiemu uzytkownikowi az pierwszy skonczy swoje dzialanie
  • ten drugi uzytkownik musi poczekac az drugi skonczy
  • pesimistic locking jest jak toitoi - jak jedna osoba wejdzie to inne musza poczekac az sie toitoi zwolni

-> Optimistic vs Pessimistic Locking

  • uzytkownicy nie lubia czekac w aplikacjach internetowych
  • najwieksza wada pessimistic locking jest to ze uzytkownicy musza czekac
  • optimistic locking jest lepszy w aplikacjach internetowych
  • zjawisko dead locka - sytuacja w ktorej dwa watki czekaja na siebie nawzajem
  • pessimistic locking moze doprowadzic do dead locka - tzw. waskie gardlo
  • moze dojsc do niezwolnienia zasobu i wtedy aplikacja sie zacina
  • czesciej uzywa sie optimistic locking

-> Timeout

  • w praktyce ustawia sie timeout zeby osoby czekajace na zasoby nie czekaly wiecznosc

About

Examples from 16 workshop zajavka about Hibernate

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages