आपको रात में चलने वाला ऐसा job चाहिए जो दो करोड़ rows पढ़े, उन्हें बदले और नतीजे लिखे। आप इसे ऐसे कैसे लिखेंगे कि मेमोरी खत्म न हो?

पूरा उठाने की जगह stream करें: scrollable cursor या keyset paging से पढ़ें, fetch size सेट करें ताकि driver सब कुछ buffer न कर ले, और chunks में process करते हुए हर chunk पर commit करें। JPA इस्तेमाल कर रहे हैं तो हर chunk के बीच persistence context clear करें या stateless session लें, वरना हर entity first level cache में पड़ी रहती है। writes को JDBC batching से batch करें, और job को आखिरी commit हुए chunk से दोबारा चालू होने लायक बनाएं।

मूल नियम यह है कि कोई भी कदम दो करोड़ चीजें एक साथ न पकड़े। मैं primary key पर keyset paging से पढ़ता हूं, या साफ fetch size वाले scrollable cursor से, और यह जानना जरूरी है कि कुछ drivers उसे अनदेखा करके पूरा result set buffer कर लेते हैं जब तक आप autocommit बंद करके transaction के भीतर न चलें, जो लोगों को तब पता चलता है जब process शुरू होने से पहले ही heap भर जाता है। फिर मैं कुछ हजार के chunks में process करता हूं, JDBC batching से लिखता हूं ताकि हर row की जगह हर chunk पर एक round trip हो, और हर chunk पर commit करता हूं। JPA के साथ एक अतिरिक्त जाल persistence context है: पढ़ी गई हर entity managed रहती है, तो मेमोरी बढ़ती है और dirty checking ज्यादा ऑब्जेक्ट्स पर घूमने लगती है जिससे flushes धीमे हो जाते हैं। मैं हर chunk पर उसे clear करता हूं या stateless session लेता हूं। Restartability मेमोरी जितनी ही जरूरी है, तो job आखिरी commit हुई key दर्ज करता है, यानी एक करोड़ अस्सी लाखवीं row पर नाकामी दोबारा शुरू करने की जगह वहीं से चलती है। और मैं इसे थ्रॉटल करता हूं, क्योंकि रात दो बजे डेटाबेस भर देने वाला batch job उन लोगों पर भी असर डालता है जो जागे हुए हैं।