டெவலப்பர்கள் இப்போது நிலை கோப்புகள் (state files) மேலெழுதப்படுவது அல்லது மறைக்கப்பட்ட கோப்பு மோதல்கள் குறித்த அச்சமின்றி, ஒரே நேரத்தில் பல கோடிங்-ஏஜென்ட் அமர்வுகளைத் தொடங்க முடியும். ஒரு ஆலோசனைக் சார்ந்த "பகிர்ந்து கொள்ளாத" (share-nothing) முறை ஒவ்வொரு ஏஜென்ட்டின் பணிப்பகுதியையும் தனிமைப்படுத்துவதோடு, சாத்தியமான மோதல்கள் குறித்து எச்சரிக்கவும் செய்கிறது. இந்த அணுகுமுறை கடினமான லாக் (hard locks) முறைகளுக்குப் பதிலாக, ஒரு எளிமையான பதிவேட்டைப் (registry) பயன்படுத்துகிறது; இது வேலைகள் ஒன்றின் மேல் ஒன்று மோதும் முன்பே அதைக் கண்டறிந்து எச்சரிப்பதன் மூலம், ஒரு அமர்வு செயலிழந்தாலும் பைப்லைன்கள் தடையின்றி இயங்குவதை உறுதி செய்கிறது.
ஏன் இணையான ஏஜென்ட்கள் சிக்கலை உருவாக்குகின்றன
ஒரே களஞ்சியத்தில் (repository) ஒன்றுக்கும் மேற்பட்ட தானியங்கி கோடிங் உதவியாளர்களை இயக்குவது, குறியீடு உருவாக்கம் (code generation), சோதனை அல்லது மறுசீரமைப்பை (refactoring) வேகப்படுத்துகிறது. நடைமுறையில், இரண்டு சிக்கல்கள் உடனடியாகத் தோன்றுகின்றன.
- நிலை சிதைவு (State corruption) – இரண்டு ஏஜென்ட்கள் ஒரே நிலை கோப்பில் எழுதுகின்றன; பிந்தைய எழுத்து முந்தையதை மேலெழுதி, முன்னேற்றத்தை அழித்துவிடுகிறது.
- கோப்பு மோதல் (File collision) – இரண்டு ஏஜென்ட்கள் ஒருவருக்கொருவர் தெரியாமல் ஒரே மூலக் கோப்பை (source file) திருத்துகின்றன. ஒரு 'diff' மாறுபட்ட மாற்றங்களைக் காட்டும் போது, இந்த மோதல் பின்னர் தெரியவருகிறது.
இந்த இரண்டு சிக்கல்களும் டெவலப்பர்களின் நேரத்தை வீணடிப்பதோடு, கண்டறிவதற்கு கடினமான பிழைகளையும் (bugs) ஏற்படுத்தக்கூடும்.
"பகிர்ந்து கொள்ளாத" விதி
இதன் அடிப்படை யோசனை எளிமையானது: ஒவ்வொரு ஏஜென்ட்டிற்கும் வட்டில் (disk) அதன் சொந்தத் தனிப்பட்ட தற்காலிகப் பகுதி (scratchpad) ஒதுக்கப்படும், மேலும் அது அந்த அமர்விற்குச் சொந்தமான கோப்புகளில் மட்டுமே எழுதும். ஒவ்வொரு கிளான்ச்-க்கும் (branch) ஒரு பகிரப்பட்ட கோப்பு மட்டுமே அனுமதிக்கப்படும், மேலும் அது "கடைசியாக எழுதுபவரே வெற்றி பெறுவார்" (last-writer-wins) என்ற விதியைப் பின்பற்றும்—எந்த ஏஜென்ட் கடைசியாக எழுதுகிறதோ, அதுவே இறுதி உள்ளடக்கத்தைத் தீர்மானிக்கும்.
ஒரு இருப்பு அடுக்கு (presence layer) ஒவ்வொரு செயல்பாட்டிலுள்ள அமர்வையும் கண்காணிக்கிறது:
- கிளான்ச் பெயர் (Branch name)
- மாற்றப்படும் கோப்புகளின் பட்டியல்
- கடைசி செயல்பாட்டின் நேர முத்திரை (Timestamp)
ஒரு புதிய அமர்வு தொடங்கும்போது, அது பதிவேட்டைச் சரிபார்க்கிறது. ஏற்கனவே மற்றொரு அமர்வு அதே கோப்புகளைக் கையாண்டு கொண்டிருந்தால், எந்த வேலையும் தொடங்குவதற்கு முன்பே டெவலப்பருக்கு ஒரு எச்சரிக்கை அனுப்பப்படும்.
ஆலோசனைக் கட்டுப்பாடுகள் (Advisory) vs. தடுக்கும் கட்டுப்பாடுகள் (Blocking)
பாரம்பரிய லாக் கோப்புகள் (lock files) ஒரு முட்டுச்சந்திப் பாதை போலச் செயல்படுகின்றன: ஒருமுறை லாக் எடுக்கப்பட்டால், லாக் விடுவிக்கப்படும் வரை மற்ற அனைத்துச் செயல்பாடுகளும் காத்திருக்க வேண்டும். அந்த அமர்வு செயலிழந்தால் (crash), லாக் கோப்பு நீண்ட நேரம் அப்படியே இருக்கும், இதனால் பழைய லாக் கோப்புகளைத் தேடித் தேடி நீக்க வேண்டிய கட்டாயம் ஏற்படும்.
ஆலோசனைக் மாதிரி (advisory model) மிகவும் மென்மையானது. இது ஒரு சாத்தியமான மோதலைக் கண்டறியும்போது எச்சரிக்கையை மட்டும் வழங்கும், ஆனால் புதிய அமர்வைத் தடுக்காது. ஒரு பதிவேடு பதிவு பழையதாக இருந்தால்—அதாவது அதை உருவாக்கிய செயல்முறை (process) இப்போது இல்லை என்றால்—அப்படியும் சிஸ்டம் எச்சரிக்கை மட்டுமே செய்யும், தொடரலாமா வேண்டாமா என்பதை டெவலப்பரே தீர்மானிக்க அனுமதிக்கிறது.
இந்த முறையை எவ்வாறு செயல்படுத்துவது
- எழுத்தாளரைப் பொறுத்து நிலையைப் பிரித்தல் – ஒவ்வொரு ஏஜென்ட்டிற்கும் தற்காலிகக் கோப்புகள் மற்றும் நிலைகளுக்காகத் தனித் தொகுப்பகத்தை (directory) வழங்கவும். உண்மையிலேயே உலகளாவிய தரவுகளுக்கு (global data) மட்டுமே பகிரப்பட்ட கோப்புகளை ஒதுக்கி, அங்கு மட்டும் "கடைசியாக எழுதுபவரே வெற்றி பெறுவார்" என்ற விதியைப் பயன்படுத்தவும்.
- தொடங்கும் போதே விழிப்புணர்வை ஏற்படுத்துதல் – ஒரு ஏஜென்ட் தொடங்குவதற்கு முன், இருப்புப் பதிவேட்டைப் படித்து, கோரப்பட்ட கோப்புகளின் பட்டியலை ஏற்கனவே உள்ள பதிவுகளுடன் ஒப்பிடவும். ஒன்றுடன் ஒன்று மோதல் இருந்தால், வேலையைத் தற்காலிகமாக நிறுத்தி அல்லது எச்சரிக்கை செய்யவும்.
- வாசிக்கும் நேரத்தில் செயல்பாட்டைச் சரிபார்த்தல் – பதிவேட்டுப் பதிவைச் சரிபார்க்கும்போது, பதிவு செய்யப்பட்ட செயல்முறை ஐடி (process ID) இன்னும் இயக்க முறைமையில் (OS) இயங்குமா என்பதைச் சரிபார்க்கவும். செயலிழந்த செயல்முறைகளுக்குச் சொந்தமான பதிவுகளை நீக்கிவிடவும்.
- தடுக்கும் முறையை விட ஆலோசனைக் முறையைத் தேர்ந்தெடுங்கள் – டெவலப்பர்கள் கட்டுப்பாட்டைத் தக்கவைத்துக் கொள்ள அனுமதிக்கவும். ஒரு எச்சரிக்கை அவர்களுக்குத் தொடரவோ, நிறுத்தவோ அல்லது ரத்து செய்யவோ அனுமதிப்பதன் மூலம் முட்டுக்கட்டையைத் (deadlock) தவிர்க்கலாம்.
- காத்திருக்கும் நிலைகளைக் கண்காணித்தல் – பல ஏஜென்ட்கள் செயல்பாட்டில் இருக்கும்போது, டெவலப்பரின் கவனம் ஒரு தடையாகும் (bottleneck). எந்த ஏஜென்ட்கள் மனித உள்ளீட்டிற்காகக் காத்திருக்கின்றன என்பதைக் காண்பிப்பதன் மூலம், வேலைகளுக்கு முன்னுரிமை அளிக்க முடியும்.
இவை அனைத்தையும் சாதாரண JSON கோப்புகள் கொண்ட ஒரு தொகுப்பகத்தைக் கொண்டே உருவாக்க முடியும்; இதற்கு வெளிப்புறத் தரவுத்தளம் (database) அல்லது மெசேஜ் பஸ் (message bus) தேவையில்லை. இந்த எளிமையான சேமிப்பு வடிவம், அமைப்பைத் தணிக்கை (audit) செய்வதற்கும் பல்வேறு சூழல்களில் எளிதாகப் பயன்படுத்துவதற்கும் (portable) உதவுகிறது.
அபாயங்கள் மற்றும் மறுப்புரைகள்
ஒரு கடினமான லாக் (hard lock) பாதுகாப்பை உறுதி செய்யும் என்று சில குழுக்கள் வாதிடலாம்: எந்த இரண்டு ஏஜென்ட்களும் ஒரே கோப்பில் எழுத முடியாது. ஆனால் இதன் சவால் அதன் குறைவான மீள்தன்மை (resilience) ஆகும்—செயலிழந்த அமர்வுகள் கைவிடப்பட்ட லாக் கோடுகளை (orphaned locks) விட்டுச் செல்லும், இது முழுப் பணிப்பாய்வையும் (workflow) முடக்கிவிடும்.
கவனிக்க வேண்டியவை
நீங்கள் பல AI சார்ந்த கோடிங் உதவியாளர்களைக் கையாள்கிறீர்கள் என்றால், "பகிர்ந்து கொள்ளாத" ஆலோசனைக் முறை அவை ஒன்றோடொன்று மோதிக்கொள்ளாமல் இருக்க ஒரு நடைமுறை வழியை வழங்குகிறது. நிலையைப் தனிமைப்படுத்துவதன் மூலமும், நோக்கத்தை முன்கூட்டியே வெளிப்படுத்துவதன் மூலமும், மனிதர்களே தொடரலாமா என்பதைத் தீர்மானிக்க அனுமதிப்பதன் மூலமும், இந்த முறை நவீன மேம்பாட்டுப் பைப்லைன்கள் (development pipelines) கோரும் நெகிழ்வுத்தன்மையுடன் பாதுகாப்பையும் சமநிலைப்படுத்துகிறது.