फ्लेक्स - बैकएंड डेटाबेस के साथ सिंक में क्लाइंट डेटा रखने के लिए सबसे अच्छी रणनीति?

Question

ब्लैजडीएस एएमएफ रीमोटिंग का उपयोग करते हुए एक एडोब फ्लेक्स आवेदकॉन में, स्थानीय डेटा को ताजा रखने और बैकएंड डेटाबेस के साथ सिंक करने के लिए सबसे अच्छी रणनीति क्या है?

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

फ्लेक्स एप्लिकेशन में, टैब, पैनल इत्यादि में साझा किए जाने के लिए अधिक डेटा अप-फ्रंट लोड करने का अस्थायीता है। यह डेटा आमतौर पर बैकएंड से अक्सर ताज़ा होता है, इसलिए इसमें होने का एक बड़ा मौका है बाँध - बचत करते समय समस्याओं का कारण बनता है, आदि

तो, इस समस्या को दूर करने का सबसे अच्छा तरीका क्या है?

ए। फ्लेक्स एप्लिकेशन का निर्माण करें जैसे कि यह एक वेब ऐप था - प्रत्येक संभावित दृश्य परिवर्तन पर बैकएंड डेटा को फिर से लोड करें

बी। समस्या को अनदेखा करें और जब वे होते हैं तो परेशान डेटा के मुद्दों से निपटें (परेशान उपयोगकर्ताओं के जोखिम पर जो स्टेल डेटा के साथ काम करने की अधिक संभावना रखते हैं)

सी। कुछ और

मेरे मामले में, LiveCycle RTMP के माध्यम से डेटा चैनल को खोलना एक विकल्प नहीं है।

Answer 1

अतीत में मैं "ए" पसंद के साथ चला गया हूं। यदि आप रिमोट ऑब्जेक्ट्स का उपयोग कर रहे थे तो आप रिमोट एंड पर सिंक में रखने के लिए कुछ कैश-स्टाइल लॉजिक सेट कर सकते हैं।

सैम

Answer 2

आप HTTP पर (HTTP मतदान) RTMP का उपयोग नहीं कर सकते हैं? इस तरह आप अभी भी आरटीएमपी का उपयोग कर सकते हैं, और हालांकि यह वास्तविक आरटीएमपी की तुलना में बहुत धीमी है, फिर भी आप इस तरह से अपडेट को ब्रॉडकास्ट कर सकते हैं।

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

Answer 3

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

Answer 4

ए। प्रॉक्सी के माध्यम से बैक-एंड परिवर्तनों को अनुकूलित करने पर विचार करें जो इसकी स्वयं की अधिसूचना या पॉलिंग करता है: यह जानता है कि कोई भी डेटा गंदा है, और यदि नहीं, तो त्वरित वापसी (एक ला 304) होगा।

बी। अक्सर, उपयोगकर्ता स्पर्श करने से अधिक दिखते हैं। देखने के लिए ताज़ा करने के एक स्तर पर विचार करें और जब वे शुरू करें और संपादित करना जारी रखें।

BuzzWord पर देखें: यह संपादन पर ताले लगाता है, लेकिन स्वचालित रूप से स्वचालित रूप से बचाता है और अनलॉक करता है।

चीयर्स

Answer 5

आपको एक अधिसूचना तंत्र के लिए, आप BlazeDS से चैनलों के साथ यह करना है और एक स्ट्रीमिंग/लंबे मतदान रणनीति

Answer 6

मैं इस लेख पाया उपयोग कर सकते हैं में LiveCycle और RTMP की जरूरत नहीं है सिंक्रनाइज़ेशन के बारे में:

http://www.databasejournal.com/features/sybase/article.php/3769756/The-Missing-Sync.htm

यह तकनीकी जानकारी में जाने नहीं करता, लेकिन आप अनुमान लगा सकते हैं क्या कोडिंग की तरह इस रणनीति को लागू करेगा।

मेरे पास मेरे सर्वर से फैंसी सूचनाएं भी नहीं हैं इसलिए मुझे सिंक्रनाइज़ेशन रणनीतियों की आवश्यकता है।

उदाहरण के लिए मेरे पास मेरे मॉडल लोकेटर में कंपनियों की एक सूची है। यह वास्तव में अक्सर नहीं बदलता है, यह पेजिनेशन पर विचार करने के लिए काफी बड़ा नहीं है, मैं प्रत्येक उपयोगकर्ता कार्रवाई पर इसे सभी (removeAll()) को पुनः लोड नहीं करना चाहता हूं, लेकिन फिर भी मैं नहीं चाहता कि मेरा एप्लिकेशन क्रैश हो या दूषित डेटा अपडेट करें अगर इसे अद्यतन किया गया है या आवेदन के दूसरे उदाहरण से हटा दिया गया है।

अब मैं जो कुछ करता हूं वह चयन समय पर सहेज रहा है। जब मैं डेटा को रीफ्रेश करने के लिए वापस आ जाता हूं तो मैं कहता हूं कि आखिरी_मोडाइफाइड> $ सत्र ['अंतिम लोड']

इस तरह से मुझे डेटा लोड करने के बाद केवल पंक्तियों में संशोधन किया जाता है (अधिकांश समय 0 पंक्तियां)।

जाहिर है आपको प्रत्येक INSERT और अद्यतन पर last_modified अद्यतन करने की आवश्यकता है।

इसे हटाने के लिए यह अधिक कठिन है। जैसा कि लड़का अपने लेख में इंगित करता है: "हम एक रिकॉर्ड कैसे भेज सकते हैं जो अब मौजूद नहीं है"

आपको फ्लेक्स को यह बताने की ज़रूरत है कि उसे किस आइटम को हटाना चाहिए (आईडी द्वारा कहें) ताकि आप वास्तव में DELETE पर समाप्त नहीं कर सकें:)

जब कोई उपयोगकर्ता किसी कंपनी को हटाता है तो आप इसके बजाय एक अद्यतन करते हैं: हटाया गया = 1 फिर रीफ्रेश कंपनियों पर, पंक्ति के लिए जहां हटाया गया = 1 आप केवल फ्लेक्स पर आईडी भेजते हैं ताकि यह सुनिश्चित हो सके कि यह कंपनी नहीं है मॉडल में अब और।

अंतिम लेकिन कम से कम नहीं, आपको एक ऐसी कार्य लिखनी होगी जो हटाए गए पंक्तियों को हटा दें = 1 और last_modified पुराना है ... 3 दिन या जो कुछ भी आपको लगता है वह आपकी आवश्यकताओं के अनुरूप है।

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

Answer 7

फ्लेक्स क्लाइंट पर कैशिंग करने की बजाय, सर्वर पक्ष पर कैशिंग क्यों नहीं करते? कुछ कारणों,

1) आप, अपने केंद्रीकृत सर्वर साइड पर डाटा को कैश और आप सुनिश्चित करें कि सभी ग्राहकों के डेटा का एक ही राज्य है

2) कैशिंग के लिए सर्वर साइड पर ज्यादा बेहतर विकल्प उपलब्ध हैं कर सकते हैं जब बल्कि फ्लेक्स की तुलना में। इसके अलावा आप एक क्रॉन नौकरी कर सकते हैं जो कुछ आवृत्ति के आधार पर डेटा को हर 24 घंटों में बताता है।

3) डेटा के रूप में सर्वर पर संचित है और यह, फ्लेक्स के साथ संचार बहुत तेजी से हो जाएगा हर बार डाटाबेस से यह लाने की जरूरत नहीं है

सादर, तेजस