एक्लिप्सलिंक में एकल अनुरोध का विश्लेषण और अनुकूलन

इस लेख में, मैंने कुछ उपयोगी प्रथाओं को इकट्ठा करने का फैसला किया, जो मैंने वास्तविक जीवन के उदाहरण के आधार पर एक्लिप्सलिंक ORM ढांचे के साथ काम करने के दो वर्षों में सीखा।
यह लेख उन लोगों के लिए है जो पहले से ही JPA पर आधारित ढांचे के साथ काम कर चुके हैं, चाहे वह हाइबरनेट हो या OpenJPA।


परियोजना, जिसके उदाहरण मैं उद्धृत करूंगा, वसंत पर आधारित है।

समस्या:

निम्न तालिकाएँ उपलब्ध हैं

ARTICLES -> Article.java ( ID int, NAME varchar ); ARTICLE_ROLES ( ARTICLE_ID int, ROLE_ID int ); ROLES -> Role.java ( ID int, NAME varchar ); 

रोल कुछ पंक्तियों के साथ एक मानक लुकअप तालिका है।

तदनुसार, इकाई अनुच्छेद में, हम JoinTable के माध्यम से एक कनेक्शन को परिभाषित करते हैं:

 @ManyToOne(optional = false, targetEntity = Role.class, fetch = FetchType.EAGER, cascade = { CascadeType.MERGE, CascadeType.REFRESH }) @JoinTable(name = "ARTICLE_ROLES", joinColumns = {@JoinColumn(name = "ARTICLE_ID", referencedColumnName="ID", nullable = false}, inverseJoinColumns = {@JoinColumn(name = "ROLE_ID", referencedColumnName = "ID", nullable = false)}) public Role getRole() { return role; } 

अब हम क्वेरी को परिभाषित करते हैं - getAllArticles निम्नानुसार हैं:

 @NamedQuery(name = "Article. getAllArticles", query = "SELECT s FROM Article s") 

और एक हफ्ते बाद, डेटाबेस में दस हजार लेख होने से, हमें खराब प्रदर्शन के बारे में शिकायतें मिलनी शुरू हो जाती हैं। समस्या।

समस्या विश्लेषण:

आरंभ करने के लिए, हम यह मापने के लिए EclipseLink PerformanceMonitor का उपयोग करेंगे कि वास्तव में कितने डेटाबेस प्रश्न JPA के माध्यम से जाते हैं।
इसे सक्षम करने का सबसे आसान तरीका दृढ़ता के माध्यम से है। xml

 <persistence> … <properties> … <property name="eclipselink.profiler" value="PerformanceMonitor"/> </properties> </persistence-unit> </persistence> 

लेकिन हमारे साथ दृढ़ता। Xml परीक्षण और अनुप्रयोग दोनों के लिए सामान्य हो सकती है।
लेकिन बीन्स। xml वे अलग हैं। इसलिए परीक्षणों के लिए इसमें लिखना पर्याप्त है:

 <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"> … <property name="jpaPropertyMap"> <map> <entry key="eclipselink.profiler" value="PerformanceMonitor" /> </map> </property> </bean> 

अब हम परीक्षण में अपने प्रोफाइलर का उपयोग करेंगे।

 PerformanceMonitor profiler = (PerformanceMonitor)em.unwrap(Session.class).getProfiler(); 

PerformanceMonitor में एक Map होता है, जिसमें यह सभी सूचनाओं को संग्रहीत करता है, जो डेटाबेस प्रश्नों की कुल संख्या से शुरू होता है, और प्रत्येक के लिए समय के साथ समाप्त होता है।
हम दो विशिष्ट मापदंडों में रुचि रखते हैं: काउंटर: ReadAllQuery और काउंटर: ReadObjectQuery।
उन्हें प्राप्त करें और पहले और बाद की तुलना करें।

 Long before = profiler.getOperationTimings.get("Counter:ReadAllQuery") + profiler.getOperationTimings.get("Counter:ReadObjectQuery "); em.createNamedQuery("Article.getAllArticles").getResultList(); Long after = profiler .getOperationTimings.get("Counter:ReadAllQuery") + profiler.getOperationTimings.get("Counter:ReadObjectQuery "); 

यह पता लगाने के लिए कि अंतर 1 नहीं है, जैसा कि आप उम्मीद कर सकते हैं, लेकिन 10001। आउच।

तथ्य यह है कि भ्रूण = FetchType.EAGER के बावजूद, JoinTable का उपयोग करते समय, JPA संबंधित पंक्ति वस्तु को प्राप्त करने के लिए प्रत्येक पंक्ति के लिए एक अनुरोध उत्पन्न करने का निर्णय लेता है।

समाधान, पहला संस्करण:

एक संकेत जोड़ें जो JPA को बताता है कि डेटा कैसे लाया जाए

 @NamedQuery(name = "Article. getAllArticles", query = "SELECT s FROM Article s", hints = { <b>@QueryHint(name = QueryHints. FETCH, value = "s.role")</b>) 

इस संकेत के वाक्य विन्यास पर विचार करें।
बेटी के हिस्से को प्रश्न के पाठ में वस्तु के उपनाम के अनुरूप होना चाहिए।
यदि आप गलती से एक अलग पत्र का उपयोग करते हैं, तो संकेत एक त्रुटि को फेंकने के बिना चुपचाप काम नहीं करेगा।
अवधि के बाद का हिस्सा अनुच्छेद के अंदर सदस्य के नाम से मेल खाना चाहिए।

 public class Article { … Role <b>role</b>; … } 

सब कुछ ठीक है, अब डेटाबेस बिल्कुल एक क्वेरी तक पहुंचता है। लेकिन हमें अचानक पता चलता है कि अनुरोध के द्वारा लौटी संख्या अब पहले की तरह दस हजार नहीं है, बल्कि केवल नौ है। समस्या।

समाधान, दूसरा संस्करण।

तथ्य यह है कि QueryHints.FETCH JOIN का उपयोग करने के लिए अनुरोध को फिर से लिखता है। लेकिन अगर JOIN TABLE में कोई संगत लाइन नहीं है (लेख में आवश्यक भूमिका निर्धारित नहीं है), तो मुख्य लाइन वापस नहीं आएगी।
सौभाग्य से, इस मामले के लिए QueryHints.LEFT_FETCH है।

अंतिम समाधान इस तरह दिखेगा:

 @NamedQuery(name = "Article. getAllArticles", query = "SELECT s FROM Article s", hints = { @QueryHint(name = QueryHints.LEFT_FETCH, value = "s.role")) 

डेटाबेस के लिए एक क्वेरी, सभी ऑब्जेक्ट जिनके बिना आपको क्वेरी टेक्स्ट को इस तरह बदलना होगा।