2009-01-05 13 views
6

क्या हाइबरनेट के लिए एक व्यवहार्य विकल्प है? अधिमानतः ऐसा कुछ जो जेपीए पर आधारित नहीं है।हाइबरनेट या टॉपलिंक का विकल्प?

हमारी समस्या यह है कि हम जटिल बना रहे हैं (जैसा कि, कई वस्तुओं एक दूसरे को संदर्भित करते हैं) राज्यव्यापी आरआईए प्रणाली। ऐसा लगता है कि हाइबरनेट को मुख्य रूप से एक-ऑफ अनुप्रयोगों - जेएसएफ और इसी तरह इस्तेमाल करने के लिए डिज़ाइन किया गया है।

समस्या मुख्य रूप से आलसी लोडिंग की है। चूंकि प्रारंभिकरण और वास्तव में आलसी संग्रह लोड करने के बीच कई HTTP अनुरोध हो सकते हैं, इसलिए प्रति लेनदेन एक सत्र प्रश्न से बाहर है। एक लंबे समय तक रहने वाला सत्र (प्रति आवेदन एक) अच्छी तरह से काम नहीं करता है, क्योंकि एक बार जब लेनदेन एक झटके को मारता है और अपवाद फेंकता है, तो पूरा सत्र अमान्य हो जाता है, इस प्रकार आलसी भारित वस्तुएं टूट जाती हैं। फिर वहां सभी प्रकार की चीजें हैं जो हमारे लिए काम नहीं करती हैं (जैसे प्रारंभिक लेनदेन के बाहर से डेटा के अंतर्निहित डेटा)।

मेरी खराब स्पष्टीकरण एक तरफ है, नीचे की रेखा यह है कि हाइबरनेट जादू करता है जिसे हम पसंद नहीं करते हैं। ऐसा लगता है कि टॉपलिंक कोई बेहतर नहीं है, यह ईजेबी के शीर्ष पर भी लिखा जा रहा है।

तो, एक स्टेटलेस दृढ़ता परत (या यहां तक ​​कि उज्ज्वल-पर्याप्त ऑब्जेक्ट उन्मुख डेटाबेस अबास्ट्रक्शन परत) वह है जिसे हमें सबसे अधिक आवश्यकता होगी।

कोई विचार, या मैं कुछ ऐसा मांग रहा हूं जो अस्तित्व में नहीं है?

संपादित करें: मुझे अपनी संदिग्ध शब्दावली के लिए खेद है, और आपके सुधार और अंतर्दृष्टिपूर्ण उत्तरों के लिए सभी को धन्यवाद। जिन्होंने मुझे सही किया, आप सभी सही हैं, मेरा मतलब है जेपीए, ईजेबी नहीं।

+0

क्या आपके प्रतिमान को ओआरएम होना चाहिए? – dacracot

उत्तर

6

जैसा कि बताया गया है, जेपीए <> ईजेबी, वे भी संबंधित नहीं हैं। ईजेबी 3 जेपीए का लाभ उठाने के लिए होता है, लेकिन यह इसके बारे में है। हमारे पास जेपीए का उपयोग करके सामान का एक गुच्छा है जो ईजेबी चलाने के करीब भी नहीं आता है।

आपकी समस्या तकनीक नहीं है, यह आपका डिज़ाइन है।

या, मुझे कहना चाहिए, आपका डिज़ाइन बहुत अधिक आधुनिक ढांचे पर एक आसान फिट नहीं है।

विशेष रूप से, आप कई HTTP अनुरोधों पर लेनदेन को जीवंत रखने की कोशिश कर रहे हैं।

स्वाभाविक रूप से, सबसे आम मुहावरे यह है कि प्रत्येक अनुरोध एक बड़े लेनदेन के हिस्से होने के बजाय प्रत्येक अनुरोध में एक या अधिक लेनदेन होता है।

एक ही चर्चा में "स्टेटलेस" और "लेनदेन" शब्द का उपयोग करते समय भी स्पष्ट भ्रम होता है, क्योंकि लेनदेन स्वाभाविक रूप से राज्यव्यापी होते हैं।

आपका बड़ा मुद्दा मैन्युअल रूप से आपके लेनदेन का प्रबंधन कर रहा है।

यदि आप कई HTTP अनुरोधों पर लेनदेन कर रहे हैं, और उन HTTP अनुरोधों को एक दूसरे के ठीक बाद "बहुत तेज़" चलाना होता है, तो आपको वास्तव में कोई वास्तविक समस्या नहीं होनी चाहिए, बचाओ कि आपको करना होगा सुनिश्चित करें कि आपके HTTP अनुरोध डेटाबेस लेनदेन सुविधा का लाभ उठाने के लिए एक ही डीबी कनेक्शन का उपयोग कर रहे हैं।

यह सरल शब्दों में है, आप डीबी से कनेक्शन प्राप्त करते हैं, सत्र में इसे सामान देते हैं, और सुनिश्चित करते हैं कि लेनदेन की अवधि के लिए, आपके सभी HTTP अनुरोध न केवल उसी सत्र के माध्यम से जाते हैं, लेकिन इस तरह से वास्तविक कनेक्शन अभी भी मान्य है। विशेष रूप से, मुझे विश्वास नहीं है कि शेल्फ जेडीबीसी कनेक्शन बंद है जो वास्तव में एक मशीन से दूसरे मशीन में विफलता या लोड संतुलन से बच जाएगा।

तो, बस, आप डीबी लेनदेन उपयोग करना चाहते हैं, तो आप सुनिश्चित करें कि आपके एक ही DB कनेक्शन का उपयोग कर की जरूरत है।

अब, यदि आपके लंबे चलने वाले लेन-देन में "उपयोगकर्ता इंटरैक्शन" है, यानी आप डीबी लेनदेन शुरू करते हैं और उपयोगकर्ता को "कुछ करने" की प्रतीक्षा करते हैं, तो काफी सरलता से, यह डिज़ाइन सभी गलत है। आपको लगता है कि, जब तक रहते थे लेनदेन, विशेष रूप से इंटरैक्टिव वातावरण में ऐसा करने के लिए नहीं करना चाहते, बस बुरा कर रहे हैं। जैसा बैड "स्ट्रीम पार"। ऐसा मत करो बैच लेनदेन अलग हैं, लेकिन इंटरैक्टिव लंबे रहते थे लेनदेन बुरा कर रहे हैं।

आप अपने इंटरैक्टिव लेन-देन को व्यावहारिक रूप से कम रहने के रूप में रखना चाहते हैं।

अब, यदि आप यह सुनिश्चित नहीं कर सकते हैं कि आप अपने लेनदेन के लिए उसी डीबी कनेक्शन का उपयोग करने में सक्षम होंगे, तो बधाई हो, आप अपने लेनदेन को लागू कर सकते हैं। इसका मतलब है कि आप अपने सिस्टम और डेटा को डिज़ाइन करते हैं जैसे कि आपके पास बैक एंड पर कोई लेनदेन क्षमता नहीं है।

इसका अनिवार्य रूप से मतलब है कि आपको अपने डेटा को "प्रतिबद्ध" करने के लिए अपने तंत्र के साथ आने की आवश्यकता होगी।

ऐसा करने का एक अच्छा तरीका यह होगा कि आप एक ही "लेनदेन" दस्तावेज़ में अपना डेटा बढ़ाते हैं, फिर उस दस्तावेज़ को "सहेजने" दिनचर्या में फ़ीड करें जो वास्तविक काम करता है। जैसे, आप डेटाबेस में एक पंक्ति स्टोर कर सकते हैं, और इसे "सहेजे" के रूप में चिह्नित कर सकते हैं। आप अपनी सभी पंक्तियों के साथ ऐसा करते हैं, और आखिरकार एक दिनचर्या को कॉल करते हैं जो आपके द्वारा संग्रहीत किए गए सभी डेटा के माध्यम से चलता है, और इसे एक ही लेन-देन मिनी-बैच प्रक्रिया में "सहेजा गया" के रूप में चिह्नित करता है।

इस बीच, आपके सभी अन्य एसक्यूएल "अनदेखा" डेटा जो "सहेजे गए" नहीं हैं। कुछ समय के टिकटों में फेंको और एक रिपर प्रक्रिया स्कैवेंगिंग करें (यदि आप वास्तव में परेशान करना चाहते हैं - यह वास्तव में डीबी में मृत पंक्तियों को छोड़ने के लिए सस्ता हो सकता है, मात्रा पर निर्भर करता है), ये मृत "सहेजे गए" पंक्तियां हैं, क्योंकि ये हैं "असम्बद्ध" लेनदेन।

यह उतना बुरा नहीं है जितना लगता है। यदि आप वास्तव में एक स्टेटलेस वातावरण चाहते हैं, जो मेरे जैसा लगता है, तो आपको ऐसा कुछ करने की आवश्यकता होगी।

दिमाग, इन सभी में दृढ़ता तकनीक वास्तव में इसके साथ कुछ लेना देना नहीं है। समस्या यह है कि तकनीक के बजाए आप अपने लेन-देन का उपयोग कैसे करते हैं।

+0

पर एक नज़र डालेंगे। मेरी शब्दावली के अस्पष्ट होने के लिए खेद है, लेकिन आपने सिर में हमारी समस्या को मारा है। वास्तव में हमारी टीम इस समय क्या कर रही है। मैं बस उम्मीद कर रहा था कि एक आसान तरीका होगा ... –

7

यदि आप किसी अन्य जेपीए प्रदाता के बाद हैं (हाइबरनेट इनमें से एक है) तो EclipseLink पर एक नज़र डालें। यह टॉपलिंक अनिवार्यता के जेपीए 1.0 संदर्भ कार्यान्वयन की तुलना में कहीं अधिक पूर्ण रूप से प्रदर्शित है। वास्तव में, एक्लिप्ससेंक ग्लासफ़िश वी 3 फ़ाइनल के साथ भेजे गए जेपीए 2.0 संदर्भ कार्यान्वयन होगा।

जेपीए अच्छा है क्योंकि आप इसे कंटेनर के अंदर और बाहर दोनों का उपयोग कर सकते हैं। मैंने स्विंग क्लाइंट्स लिखे हैं जो अच्छे प्रभाव के लिए जेपीए का उपयोग करते हैं। इसमें एक ही कलंक और एक्सएमएल सामान नहीं है जो ईजेबी 2.0/2.1 के साथ आया था।

यदि आप हल्के वजन समाधान के बाद भी हैं तो ibatis से आगे नहीं देखें, जिसे मैं जावा प्लेटफ़ॉर्म के लिए पसंद की मेरी दृढ़ता तकनीक मानता हूं। यह हल्का वजन है, एसक्यूएल पर निर्भर करता है (यह आश्चर्यजनक है कि ओआरएम उपयोगकर्ता अपने ओआरएम को अच्छा एसक्यूएल बनाने का प्रयास करने में कितना समय व्यतीत करते हैं) और जेपीए क्या करता है (9 0-95% जो संबंधित संस्थाओं की आलसी लोडिंग सहित) करता है।

बस अंक के एक जोड़े को दूर करने के:

  • जेपीए EJB के peristence परत, EJB पर बनाया गया नहीं है,
  • किसी भी सभ्य जेपीए प्रदाता के पास बहुत सारी कैशिंग चल रही है और इसे सभी को समझना मुश्किल हो सकता है (यह "सरलता इतनी जटिल क्यों है?" का एक अच्छा उदाहरण होगा)। जब तक आप ऐसा कुछ नहीं कर रहे हैं जिसे आपने इंगित नहीं किया है, अपवाद आपके प्रबंधित ऑब्जेक्ट्स के लिए कोई समस्या नहीं होनी चाहिए। रनटाइम अपवाद आमतौर पर रोलबैक लेनदेन (यदि आप स्प्रिंग के लेनदेन प्रबंधन का उपयोग करते हैं और कौन ऐसा नहीं करता है?)। प्रदाता लोड या निरंतर वस्तुओं की कैश की गई प्रतियों को बनाए रखेगा। यह समस्याग्रस्त हो सकता है यदि आप इकाई प्रबंधक के बाहर अद्यतन करना चाहते हैं (एक स्पष्ट कैश फ्लश या EntityManager.refresh() का उपयोग करने की आवश्यकता है)।
+0

धन्यवाद, मैं आपकी टिप्पणियों के लिए धन्यवाद ibatis –

2

मैंने पिछले वर्ष SimpleORM पर देखा है, और इसके हल्के नो-जादू डिजाइन से बहुत प्रभावित था।अब एक संस्करण 3 प्रतीत होता है, लेकिन मुझे इसके साथ कोई अनुभव नहीं है।

0

न तो हाइबरनेट और न ही टॉपलिंक (एक्लिप्ससेंक) ईजेबी पर आधारित है, वे दोनों POJO दृढ़ता ढांचे (ओआरएम) हैं।

मैं पिछले उत्तर से सहमत हूं: iBatis ओआरएम ढांचे के लिए एक अच्छा विकल्प है: एक अच्छा कैशिंग तंत्र के साथ, एसक्यूएल पर पूर्ण नियंत्रण।

0

एक अन्य विकल्प टोक़ है, मैं यह नहीं कह रहा हूं कि यह उपर्युक्त विकल्पों में से किसी भी विकल्प से बेहतर है, लेकिन सिर्फ यह देखने का एक और विकल्प है। अब यह काफी पुराना हो रहा है लेकिन आपकी कुछ आवश्यकताओं को पूरा कर सकता है।

Torque

3

मुझे लगता है कि आप apache cayenne पर एक नज़र जो एक बहुत अच्छा विकल्प के लिए "बड़ी" चौखटे है होना चाहिए। अपने सभ्य मॉडलर के साथ, सीखने की अवस्था एक अच्छी प्रलेखन से कम हो जाती है।

1

बीईए कोडो (पूर्व में सोलर्मेट्रिक कोडो) एक और विकल्प है। यह जेपीए, जेडीओ, और ईजे 3 का समर्थन करता है। यह बेहद विन्यास योग्य है और आक्रामक पहले से लाना समर्थन कर सकते हैं, अलग करने/वस्तुओं के संलग्न, आदि

हालांकि, से तुम क्या वर्णन किया है, Toplink अपनी समस्याओं को संभालने के लिए सक्षम होना चाहिए। अधिकतर, ऐसा लगता है कि आप दृढ़ता परत से वस्तुओं को संलग्न/अलग करने में सक्षम होने की आवश्यकता है क्योंकि अनुरोध प्रारंभ और समाप्त होते हैं।

0

जब मैं खुद को हाइबरनेट के प्रतिस्थापन की तलाश में था तो मैंने DataNucleus Access Platform पर ठोकर खाई, जो अपाचे 2-लाइसेंस प्राप्त ओआरएम है। यह सिर्फ ओआरएम नहीं है क्योंकि यह आरडीबीएमएस की तुलना में अन्य डेटा स्रोतों में भी डेटा की दृढ़ता और पुनर्प्राप्ति प्रदान करता है, जैसे एलडीएपी, डीबी 4 ओ और एक्सएमएल। मेरे पास कोई उपयोग अनुभव नहीं है, लेकिन यह दिलचस्प लग रहा है।

0

tox जैसे कुछ के साथ पूरी तरह से अपने प्रतिमान को तोड़ने पर विचार करें। यदि आपको जावा कक्षाओं की आवश्यकता है तो आप XML परिणाम को JDOM में लोड कर सकते हैं।

2

Ebean ORM (http://www.avaje.org)

यह एक सरल और अधिक सहज ज्ञान युक्त ORM उपयोग करने के लिए है।

  • का उपयोग करता है मानचित्रण (@Entity, @OneToMany आदि)
  • Sessionless एपीआई के लिए जेपीए एनोटेशन - कोई हाइबरनेट सत्र या जेपीए इकाई प्रबंधक
  • लेज़ी लोड हो रहा है बस काम करता है
  • अधिक से अधिक प्रदर्शन
  • के लिए आंशिक वस्तु समर्थन
  • स्वचालित प्रश्न "Autofetch"
  • स्प्रिंग एकता के माध्यम से ट्यूनिंग
  • बड़े क्वेरी समर्थन
  • बैच प्रसंस्करण के लिए महान समर्थन
  • पृष्ठभूमि प्राप्त करने में कठिनाई
  • DDL पीढ़ी
  • आप कच्चे एसक्यूएल यदि आप चाहें (Ibatis रूप में अच्छा के रूप में)
  • LGPL लाइसेंस

  • रोब उपयोग कर सकते हैं।

1

बस संदर्भ के लिए, क्यों ओपी के डिजाइन उनकी सबसे बड़ी समस्या है: एकाधिक उपयोगकर्ता अनुरोधों में होने वाले लेनदेन में फैले मतलब है कि आप एक निश्चित समय पर के रूप में कई खुले लेनदेन हो सकता है वहाँ आपके एप्लिकेशन से कनेक्ट उपयोगकर्ताओं के रूप में - एक सौदे रहता है जब तक यह प्रतिबद्ध नहीं होता है तब तक कनेक्शन व्यस्त होता है। हजारों एक साथ जुड़े उपयोगकर्ताओं के साथ, इसका संभावित रूप से हजारों कनेक्शन का मतलब हो सकता है। अधिकांश डेटाबेस इसका समर्थन नहीं करते हैं।

संबंधित मुद्दे