- हां,
@BatchSizeआलसी संघों के साथ प्रयोग करने के लिए है। - हाइबरनेट वैसे भी अधिकांश स्थितियों में एकाधिक कथन निष्पादित करेगा, भले ही अनियमित प्रॉक्सी/संग्रह की संख्या निर्दिष्ट बैच आकार से कम हो। अधिक विवरण के लिए यह उत्तर देखें। साथ ही, कम बड़े प्रश्नों की तुलना में अधिक हल्के प्रश्न सिस्टम के समग्र प्रवाह में सकारात्मक योगदान दे सकते हैं।
@BatchSizeकक्षा स्तर पर इसका मतलब है कि इकाई के लिए निर्दिष्ट बैच आकार सभी@*ToOne. के लिए लागू किया जाएगा उस इकाई के साथ आलसी जुड़ाव।Person. के साथ उदाहरण देखें दस्तावेज़ीकरण में इकाई।
आपके द्वारा प्रदान किए गए लिंक किए गए प्रश्न/उत्तर सामान्य रूप से अनुकूलन और आलसी लोडिंग की आवश्यकता के बारे में अधिक चिंतित हैं। वे निश्चित रूप से यहां भी आवेदन करते हैं, लेकिन वे केवल बैच लोडिंग से संबंधित नहीं हैं, जो कि संभावित तरीकों में से एक है।
एक और महत्वपूर्ण बात उत्सुक लोडिंग से संबंधित है जिसका उल्लेख लिंक किए गए उत्तरों में किया गया है और जो यह बताता है कि यदि किसी संपत्ति का हमेशा उपयोग किया जाता है तो आप उत्सुक लोडिंग का उपयोग करके बेहतर प्रदर्शन प्राप्त कर सकते हैं। यह सामान्य तौर पर सच नहीं है संग्रह के लिए और कई स्थितियों में एक-से-एक संघों के लिए भी।
उदाहरण के लिए, मान लें कि आपके पास निम्न इकाई है जिसके लिए bs और cs हमेशा हैं उपयोग किया जाता है जब A उपयोग किया जाता है।
public class A {
@OneToMany
private Collection<B> bs;
@OneToMany
private Collection<C> cs;
}
उत्सुकता से लोड हो रहा है bs और cs स्पष्ट रूप से एन + 1 से पीड़ित समस्या का चयन करता है यदि आप उन्हें एक ही प्रश्न में शामिल नहीं करते हैं। लेकिन अगर आप उन्हें एक ही प्रश्न में शामिल करते हैं, उदाहरण के लिए:
select a from A
left join fetch a.bs
left join fetch a.cs
फिर आप पूर्ण कार्टेशियन उत्पाद बनाते हैं bs . के बीच और cs और count(a.bs) x count(a.cs) returning लौटा रहे हैं परिणाम में पंक्तियाँ प्रत्येक a . के लिए सेट की गई हैं जो एक-एक करके पढ़े जाते हैं और A . की इकाइयों में इकट्ठे होते हैं और उनके bs . के संग्रह और cs ।
इस स्थिति में बैच फ़ेचिंग बहुत इष्टतम होगी, क्योंकि आप पहले A . पढ़ेंगे s, फिर bs और फिर cs , जिसके परिणामस्वरूप अधिक प्रश्न होते हैं लेकिन डेटाबेस से स्थानांतरित किए जाने वाले डेटा की कुल मात्रा बहुत कम होती है। साथ ही, अलग-अलग क्वेश्चन जॉइन के साथ बड़ी क्वेरी की तुलना में बहुत आसान होते हैं और डेटाबेस के लिए निष्पादित और ऑप्टिमाइज़ करने के लिए आसान होते हैं।
