धडे

1.1 समस्येची पार्श्वभूमी जेव्हा तुम्ही खर्‍या डेटाबेससह काम सुरू करता तेव्हा तुम्हाला "अकाली ऑप्टिमायझेशन हे सर्व वाईटाचे मूळ आहे" हे वाक्य लगेच लक्षात येईल. फक्त आता तू तिला नकारात्मक पद्धतीने आठवतेस. डेटाबेससह कार्य करताना, ऑप्टिमायझेशन अ

2.1 आणण्याचा पर्याय हायबरनेटच्या विकसकांना बर्याच काळापासून बाल घटक लोड करण्याच्या समस्येबद्दल माहिती आहे. म्हणून त्यांनी पहिली गोष्ट केली ती म्हणजे भाष्यांमध्ये एक विशेष फेच@OneToMany पॅरामीटर जोडणे , @ManyToMany. हे पॅरामीटर दोन मूल्ये घे

LazyCollectionOption.EXTRA जाणून घेणे परंतु LazyCollectionOption.EXTRA मूल्य हे सर्वात जास्त स्वारस्य आहे. आपण @LazyCollection भाष्याचे मूल्य म्हणून निर्दिष्ट केल्यास , नंतर हायबरनेट संग्रहातील घटक लोड होण्यास विलंब करेल. आपण संग्रहातील घटक

समस्येचे वर्णन आम्ही वर म्हटल्याप्रमाणे, LazyCollectionOption.EXTRA भाष्यात समस्या आहे - ती प्रत्येक ऑब्जेक्टसाठी डेटाबेसला स्वतंत्र विनंती करते. आम्ही हायबरनेटला कसे तरी समजावून सांगणे आवश्यक आहे की आम्हाला आमच्या मूळ वस्तूंसाठी सर्व चाइल्

तुमचे कॅशिंग सोल्यूशन कधीही लिहू नका डेटाबेससह कामाचा वेग वाढवण्याचा आणखी एक मार्ग म्हणजे आम्ही आधीच विनंती केलेल्या वस्तू कॅशे करणे. महत्वाचे! तुमचे स्वतःचे कॅशिंग सोल्यूशन कधीही लिहू नका. या कार्यात इतके तोटे आहेत की आपण स्वप्नातही विचार

समवर्ती धोरणे तुम्ही हायबरनेटमध्ये द्वितीय-स्तरीय कॅशिंग सक्षम केल्यानंतर, तुम्हाला हायबरनेटला समजावून सांगावे लागेल की आम्हाला कोणते घटक ऑब्जेक्ट कॅशे करायचे आहेत आणि कसे. हे करण्यासाठी, हायबरनेटमध्ये अस्तित्व वर्गांसाठी एक विशेष भाष्य आहे

आपल्याला क्वेरी कॅशेची आवश्यकता का आहे HQL मध्‍ये कर्मचार्‍यांसह आमचे उदाहरण पुन्हा लिहू: Employee director1 = session.createQuery("from Employee where id = 4").uniqueResult();

कॅशिंग सेट करत आहे चला hibernate.cfg.xml फाईलमधील आमच्या कॅशिंग सेटिंग्जवर परत जाऊया: