ഡെവലപ്പർമാർക്ക് ഇപ്പോൾ സ്റ്റേറ്റ് ഫയലുകൾ ഓവർറൈറ്റ് ചെയ്യപ്പെടുമെന്നോ ഫയലുകൾ തമ്മിൽ കൂട്ടിമുട്ടുമെന്നോ ഉള്ള പേടിയില്ലാതെ ഒരേസമയം ഒന്നിലധികം കോഡിംഗ്-ഏജന്റ് സെഷനുകൾ സജ്ജമാക്കാം. ഒരു അഡ്വൈസറി “share-nothing” പാറ്റേൺ ഓരോ ഏജന്റിന്റെയും വർക്ക്സ്പേസ് വേർതിരിക്കുകയും സാധ്യമായ തർക്കങ്ങളെക്കുറിച്ച് മുന്നറിയിപ്പ് നൽകുകയും ചെയ്യുന്നു. ഈ രീതി കഠിനമായ ലോക്കുകൾക്ക് (hard locks) പകരം ഒരു ലഘുവായ രജിസ്ട്രി ഉപയോഗിക്കുന്നു, ഇത് ജോലികൾ തമ്മിൽ കൂട്ടിമുട്ടുന്നതിന് മുമ്പ് തന്നെ അത് അറിയിക്കുകയും സെഷനുകൾ ക്രാഷ് ആയാലും പൈപ്പ്ലൈനുകൾ തടസ്സമില്ലാതെ മുന്നോട്ട് കൊണ്ടുപോകാൻ സഹായിക്കുകയും ചെയ്യുന്നു.
പാരലൽ ഏജന്റുകൾ എവിടെയാണ് തടസ്സപ്പെടുന്നത്
ഒരു സിംഗിൾ റിപ്പോസിറ്ററിയിൽ ഒന്നിലധികം ഓട്ടോമേറ്റഡ് കോഡിംഗ് അസിസ്റ്റന്റുകൾ പ്രവർത്തിപ്പിക്കുന്നത് കോഡ് ജനറേഷൻ, ടെസ്റ്റിംഗ് അല്ലെങ്കിൽ റീഫാക്റ്ററിംഗ് എന്നിവ വേഗത്തിലാക്കുന്നു. എന്നാൽ പ്രായോഗികമായി രണ്ട് പ്രശ്നങ്ങൾ ഉടൻ തന്നെ ഉയർന്നുവരുന്നു.
- State corruption – രണ്ട് ഏജന്റുകൾ ഒരേ സ്റ്റേറ്റ് ഫയലിൽ എഴുതുന്നു; രണ്ടാമത് എഴുതുന്നത് ആദ്യത്തേതിനെ ഓവർറൈറ്റ് ചെയ്യുകയും പുരോഗതി നഷ്ടപ്പെടുത്തുകയും ചെയ്യുന്നു.
- File collision – രണ്ട് ഏജന്റുകൾ പരസ്പരം അറിയാതെ ഒരേ സോഴ്സ് ഫയൽ എഡിറ്റ് ചെയ്യുന്നു. പിന്നീട് ഒരു diff പരിശോധിക്കുമ്പോൾ മാറ്റങ്ങൾ തമ്മിലുള്ള വ്യത്യാസം കാണുമ്പോൾ മാത്രമേ ഈ പ്രശ്നം തിരിച്ചറിയാൻ കഴിയൂ.
ഈ രണ്ട് പ്രശ്നങ്ങളും ഡെവലപ്പർമാരുടെ സമയം പാഴാക്കുകയും കണ്ടെത്താൻ പ്രയാസമുള്ള ബഗുകൾ (bugs) ഉണ്ടാക്കുകയും ചെയ്യുന്നു.
“share nothing” നിയമം
ഇതിന്റെ അടിസ്ഥാന ആശയം ലളിതമാണ്: ഓരോ ഏജന്റിനും ഡിസ്കിൽ സ്വന്തമായി ഒരു പ്രൈവറ്റ് സ്ക്രാച്ച്പാഡ് ലഭിക്കുന്നു, കൂടാതെ ആ സെഷനുമായി ബന്ധപ്പെട്ട ഫയലുകളിൽ മാത്രമേ അവ എഴുതുകയുള്ളൂ. ഓരോ ബ്രാഞ്ചിലും മനഃപൂർവ്വം പങ്കുവെക്കുന്ന ഒരു ഫയൽ മാത്രമേ അനുവദിക്കൂ, അത് “last-writer-wins” എന്ന നിയമം പിന്തുടരുന്നു—ഏത് ഏജന്റാണോ അവസാനം എഴുതുന്നത്, അതാണ് അവസാന ഫയൽ ഉള്ളടക്കം നിശ്ചയിക്കുന്നത്.
ഒരു presence layer ഓരോ ആക്റ്റീവ് സെഷനെയും ട്രാക്ക് ചെയ്യുന്നു:
- ബ്രാഞ്ച് പേര് (Branch name)
- മാറ്റം വരുത്തുന്ന ഫയലുകളുടെ പട്ടിക
- അവസാന ആക്റ്റിവിറ്റിയുടെ ടൈംസ്റ്റാമ്പ്
ഒരു പുതിയ സെഷൻ തുടങ്ങുമ്പോൾ, അത് രജിസ്ട്രിയെ പരിശോധിക്കുന്നു. മറ്റേതെങ്കിലും സെഷൻ നിലവിൽ അതേ ഫയലുകൾ കൈകാര്യം ചെയ്യുന്നുണ്ടെങ്കിൽ, ജോലി തുടങ്ങുന്നതിന് മുമ്പ് ഡെവലപ്പർക്ക് ഒരു മുന്നറിയിപ്പ് ലഭിക്കും.
Advisory vs. blocking locks
പരമ്പരാഗത ലോക്ക് ഫയലുകൾ ഒരു അടഞ്ഞ പാത പോലെയാണ്: ഒരിക്കൽ ഒരു ലോക്ക് എടുക്കപ്പെട്ടാൽ, ആ ലോക്ക് മാറുന്നത് വരെ മറ്റ് പ്രക്രിയകൾ കാത്തുനിൽക്കേണ്ടി വരും. ലോക്ക് എടുത്ത സെഷൻ ക്രാഷ് ആയാൽ, ആ ലോക്ക് അവിടെത്തന്നെ തുടരാം, ഇത് പഴയ ലോക്ക് ഫയലുകൾ മാനുവലായി തിരയാൻ ഡെവലപ്പർമാരെ നിർബന്ധിക്കുന്നു.
അഡ്വൈസറി മോഡൽ കൂടുതൽ ലളിതമാണ്. ഒരു തർക്കം ഉണ്ടാകാൻ സാധ്യതയുണ്ടെന്ന് കണ്ടാൽ ഇത് മുന്നറിയിപ്പ് നൽകുന്നുണ്ടെങ്കിലും പുതിയ സെഷനെ തടയുന്നില്ല. ഒരു രജിസ്ട്രി എൻട്രി പഴയതാണെങ്കിൽ—അതായത് അത് സൃഷ്ടിച്ച പ്രോസസ്സ് നിലവിൽ ഇല്ലെങ്കിൽ—സിസ്റ്റം മുന്നറിയിപ്പ് നൽകുക മാത്രമേ ചെയ്യുന്നുള്ളൂ, തുടർന്ന് മുന്നോട്ട് പോകണോ വേണ്ടയോ എന്ന് തീരുമാനിക്കാൻ ഡെവലപ്പർക്ക് സ്വാതന്ത്ര്യമുണ്ട്.
ഈ പാറ്റേൺ എങ്ങനെ നടപ്പിലാക്കാം
- Partition state by writer – ഓരോ ഏജന്റിനും താൽക്കാലിക ഫയലുകൾക്കും സ്റ്റേറ്റിനും വേണ്ടി സ്വന്തമായി ഒരു ഡയറക്ടറി നൽകുക. ആഗോള ഡാറ്റയ്ക്കായി (global data) മാത്രം ഷെയർ ചെയ്ത ഫയലുകൾ മാറ്റിവെക്കുക, അവിടെ മാത്രം “last-writer-wins” നിയമം ബാധകമാക്കുക.
- Inject awareness at launch – ഒരു ഏജന്റ് തുടങ്ങുന്നതിന് മുമ്പ്, presence registry വായിക്കുകയും ആവശ്യപ്പെട്ട ഫയലുകളുടെ പട്ടിക നിലവിലുള്ളവയുമായി താരതമ്യം ചെയ്യുകയും ചെയ്യുക. ഫയലുകൾ തമ്മിൽ കൂട്ടിമുട്ടുന്നുണ്ടെങ്കിൽ അത് തടയുകയോ മുന്നറിയിപ്പ് നൽകുകയോ ചെയ്യുക.
- Verify liveness at read time – ഒരു രജിസ്ട്രി എൻട്രി പരിശോധിക്കുമ്പോൾ, രേഖപ്പെടുത്തിയ പ്രോസസ്സ് ഐഡി (process ID) ഇപ്പോഴും ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൽ പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക. നിലവിലില്ലാത്ത പ്രോസസ്സുകളുടെ എൻട്രികൾ ഒഴിവാക്കുക.
- Prefer advisory over blocking – ഡെവലപ്പർമാരുടെ നിയന്ത്രണം നിലനിർത്തുക. ഒരു മുന്നറിയിപ്പ് നൽകുന്നതിലൂടെ അവർക്ക് ജോലി തുടരാനോ, നിർത്താനോ, അല്ലെങ്കിൽ റദ്ദാക്കാനോ സാധിക്കും, ഇത് ഡെഡ്ലോക്ക് (deadlock) ഒഴിവാക്കുന്നു.
- Track waiting states – ഒന്നിലധികം ഏജന്റുകൾ സജീവമാകുമ്പോൾ, ഡെവലപ്പറുടെ ശ്രദ്ധയാണ് പ്രധാന തടസ്സമായി മാറുന്നത്. ഏതെല്ലാം ഏജന്റുകളാണ് മനുഷ്യന്റെ സഹായത്തിനായി കാത്തുനിൽക്കുന്നത് എന്ന് കാണിക്കുക, അങ്ങനെ ജോലികൾക്ക് മുൻഗണന നൽകാൻ സാധിക്കും.
ഇതെല്ലാം ലളിതമായ JSON ഫയലുകൾ ഉപയോഗിച്ച് നിർമ്മിക്കാം; ഇതിനായി പുറത്തുനിന്നുള്ള ഡാറ്റാബേസോ മെസേജ് ബസ്സോ ആവശ്യമില്ല. ലളിതമായ സ്റ്റോറേജ് ഫോർമാറ്റ് കാരണം സിസ്റ്റം ഓഡിറ്റ് ചെയ്യാനും വിവിധ സാഹചര്യങ്ങളിൽ (environments) എളുപ്പത്തിൽ ഉപയോഗിക്കാനും സാധിക്കും.
അപകടസാധ്യതകളും എതിർപ്പുകളും
ഒരു ഹാർഡ് ലോക്ക് സുരക്ഷ ഉറപ്പാക്കുന്നു എന്ന് ചില ടീമുകൾ വാദിച്ചേക്കാം: രണ്ട് ഏജന്റുകൾക്കും ഒരേ ഫയലിൽ ഒരിക്കലും എഴുതാൻ കഴിയില്ല. എന്നാൽ ഇതിന്റെ പോരായ്മ എന്നത് കുറഞ്ഞ പ്രതിരോധശേഷിയാണ് (resilience)—ക്രാഷ് ആയ സെഷനുകൾ അവശേഷിപ്പിക്കുന്ന ലോക്കുകൾ മുഴുവൻ വർക്ക്ഫ്ലോയെയും തടസ്സപ്പെടുത്തുന്നു.
ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
നിങ്ങൾ ഒന്നിലധികം AI അധിഷ്ഠിത കോഡ് അസിസ്റ്റന്റുകൾ ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ, അവ പരസ്പരം തടസ്സമാകാതിരിക്കാൻ “share nothing” അഡ്വൈസറി പാറ്റേൺ ഒരു പ്രായോഗിക മാർഗ്ഗമാണ്. സ്റ്റേറ്റ് വേർതിരിച്ചും, ഉദ്ദേശ്യങ്ങൾ നേരത്തെ അറിയിച്ചും, മനുഷ്യർക്ക് തീരുമാനമെടുക്കാൻ അവസരം നൽകിയും, ഈ രീതി സുരക്ഷയും ആധുനിക ഡെവലപ്മെന്റ് പൈപ്പ്ലൈനുകൾക്ക് ആവശ്യമായ ഫ്ലെക്സിബിലിറ്റിയും ഒരുപോലെ നൽകുന്നു.