Hibernate and Application Performance

 hibernate 2 cur cache memory var:

L1(Level bir) burada entitymanager a aiddir. bazadan gelen entityler cacheda saxlanir ve her entitymanagere xasdir

L2(level 2) burada ise umumiyyetle EntityManagerFactory ye xidmet eden entiymanagerler arasinda shared cache memorydir ve level 1 den daha uzun muddetlidir

level 2 cache i aktivleshdirmek uchun dependency elave edilir projecte ve 1-2 config edilir

Javada 4 cur reference type var :

https://dzone.com/articles/reference-types-java-part-1

1. Strong references.
2. Soft references.
3. Weak references.
4. Phantom references

entitymanager de weak referance var , ve o strongla muqayisede GC terefinden istenilen an siline biler ram lazim olsa.

soft referance - strongdan zeif , weakdan gucludur ve GC onu ancaq en vacib hallarda sile biler, weak i her memory chatmiyanda sile biler ama softu ancaq outofmemory alacagi teqdirde silib ishlede biler ve soft un omru uzun olur . ve Level 2 cache da istifade edir bunu hibernate. burda da bele shey varki , LRU(last recently used) yeniki mueyyen say qeder cache saxliyir ondan artiqnin saxlamir ve her yeni cache gelende konhe silinir uzaqda olan

numune :

Student student = new Student();

SoftReference softReference = new SoftReference(student);

student = null;

softReference.get();

burada gorunduyu kimi ilk setir strong reference a aiddir , 2 ci ise soft a. burada strong reference null olan kimi GC onu silecek . amma soft a bu tesir etmeyecek taaki jvm outofmemeory vermiyene qeder

Student student = new Student();

WeakReference weakReference = new WeakReference(student);

student = null;

weakReference.get();

ancaq bu case da , strong referencein null olmasi , weak a tesir ede biler ve GC gorseki memeorye ehtiyac var onu istediyi an sile biler

ama bunlarin hech biri zemanet vermirki student objecti qayida biler, chunki arxada GC lazim olanda reference i sile biler ve null qayidar

hibernate ise bunlari cache uchun istifade edir ve eger null qayitsa basha dushurki bazaya sorgu verib yeniden load etmek lazimdir

PhantomReference biraz ferqli ishleyir , demeli deyekki video load olub jvm e ve olchusu boyukdur 2 ci vidoe yukelnse OutOfMemory ala bilerik . ama ramda yer var mueyyen qeder bu ise 2 ci videoya kifayet elemir ve GC da bosh yeri gorub ishlemir , bu case da biz bu emelyati PhantomReference ile ede bilerik ve bu GC uchun trigger rolu oynayacaq . ne vaxtki video process olub qutarir GC ni trigger edirler ve o lazimsiz yeri silir

@Transactional annotation:

method levelde istifade olunur  , ve ilk db emelyati bashliyandan son db emelyati qutarana qeder transaction achiq qalir  , tutaqki 2 entity dalbadal bazaya save olmalidi amma 1 ci save olunur 2 ci save olunmur hansisa sebebden, bu case da exception olur ve try catchda tutulur onda rollback edir ve hec bir data bazaya yazilmir(bu prosesler arxada bash verir) eger her 2 si success dise onda ok transaction commit olur ve emelyat sona chatir

Diqqet!!! eger @Transactional istifade olunmasa onda bu rollback emelyati olmyacaq ve db de qarishiq vezyet yaranacaq(1 ci save olunacacaq, 2 ci yox)

Diqqet!!! amma bu annotation un ishlemesi uchun bezi shertler var:

gerek method public olsun ve servisin methodunu bashqa yerden chagirsinlar (her 2 shert odenmelidir!)

sebebi odurki , transaction meselesi proxy uzerinden gedir (spring de dependency injection meselesi ile elaqedar) ve bashqa clasdan cchagrilish olanda bu proxy istifade olunur spring terefinden , amma eyni class daxili chagrilish olanda proxy istifade olunmur ve neticede springin o methodun chagrilmagindan xeberi olmur

Transaction haqqinda maraqli caselar:

https://codete.com/blog/5-common-spring-transactional-pitfalls/

Rollback la bagli maraqli meqam :

@Transactional ancaq unchecked exception halinda rollback edir emelyati , eger checked exception olsa etmir