ಡೆವಲಪರ್ಗಳು ಸ್ಟೇಟ್ ಫೈಲ್ಗಳು (state files) ಓವರ್ರೈಟ್ ಆಗುವ ಅಥವಾ ಫೈಲ್ಗಳ ನಡುವೆ ಸಂಘರ್ಷ ಉಂಟಾಗುವ ಭಯವಿಲ್ಲದೆ ಏಕಕಾಲದಲ್ಲಿ ಹಲವಾರು ಕೋಡಿಂಗ್-ಏಜೆಂಟ್ ಸೆಷನ್ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು. ಒಂದು ಸಲಹೆಯ (advisory) “share-nothing” ಮಾದರಿಯು ಪ್ರತಿಯೊಂದು ಏಜೆಂಟ್ನ ವರ್ಕ್ಸ್ಪೇಸ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ ಮತ್ತು ಸಂಭಾವ್ಯ ಸಂಘರ್ಷಗಳ ಬಗ್ಗೆ ಎಚ್ಚರಿಸುತ್ತದೆ. ಈ ವಿಧಾನವು ಹಾರ್ಡ್ ಲಾಕ್ಗಳ ಬದಲಿಗೆ (hard locks) ಲಘು ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ಬಳಸುತ್ತದೆ, ಇದು ಕೆಲಸಗಳು ಒಂದಕ್ಕೊಂದು ಅಡ್ಡ ಬರುವ ಮೊದಲೇ ಸೂಚಿಸುತ್ತದೆ, ಇದರಿಂದ ಸೆಷನ್ ಕ್ರ್ಯಾಶ್ ಆದಾಗಲೂ ಪೈಪ್ಲೈನ್ಗಳು ನಿರಂತರವಾಗಿ ಚಲಿಸುತ್ತವೆ.
ಸಮಾಂತರ ಏಜೆಂಟ್ಗಳು ಏಕೆ ತೊಂದರೆ ನೀಡುತ್ತವೆ
ಒಂದೇ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸ್ವಯಂಚಾಲಿತ ಕೋಡಿಂಗ್ ಅಸಿಸ್ಟೆಂಟ್ಗಳನ್ನು ಚಲಾಯಿಸುವುದು ಕೋಡ್ ಜನರೇಷನ್, ಟೆಸ್ಟಿಂಗ್ ಅಥವಾ ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ. ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಎರಡು ಸಮಸ್ಯೆಗಳು ತಕ್ಷಣವೇ ಎದುರಾಗುತ್ತವೆ.
- State corruption (ಸ್ಥಿತಿ ದೋಷ) – ಎರಡು ಏಜೆಂಟ್ಗಳು ಒಂದೇ ಸ್ಟೇಟ್ ಫೈಲ್ಗೆ ಬರೆಯಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ನಂತರದ ಬರವಣಿಗೆಯು ಮೊದಲಿನ ಬರವಣಿಗೆಯನ್ನು ಓವರ್ರೈಟ್ ಮಾಡಿ, ಪ್ರಗತಿಯನ್ನು ಅಳಿಸಿಹಾಕುತ್ತದೆ.
- File collision (ಫೈಲ್ ಸಂಘರ್ಷ) – ಎರಡು ಏಜೆಂಟ್ಗಳು ಒಬ್ಬರಿಗೊಬ್ಬರು ತಿಳಿಯದೆಯೇ ಒಂದೇ ಸೋರ್ಸ್ ಫೈಲ್ ಅನ್ನು ಎಡಿಟ್ ಮಾಡುತ್ತಾರೆ. ನಂತರ 'diff' ಮೂಲಕ ಬದಲಾವಣೆಗಳನ್ನು ನೋಡಿದಾಗ ಈ ಸಂಘರ್ಷವು ತಿಳಿಯುತ್ತದೆ.
ಈ ಎರಡೂ ಸಮಸ್ಯೆಗಳು ಡೆವಲಪರ್ಗಳ ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತವೆ ಮತ್ತು ಪತ್ತೆಹಚ್ಚಲು ಕಷ್ಟವಾಗುವಂತಹ ಬಗ್ಗಳನ್ನು (bugs) ಉಂಟುಮಾಡಬಹುದು.
“share nothing” ನಿಯಮ
ಇದರ ಮೂಲ ಪರಿಕಲ್ಪನೆ ಸರಳವಾಗಿದೆ: ಪ್ರತಿಯೊಂದು ಏಜೆಂಟ್ಗೆ ಡಿಸ್ಕ್ನಲ್ಲಿ ತನ್ನದೇ ಆದ ಖಾಸಗಿ ಸ್ಕ್ರ್ಯಾಚ್ಪ್ಯಾಡ್ (scratchpad) ಇರುತ್ತದೆ ಮತ್ತು ಅದು ಆ ಸೆಷನ್ಗೆ ಸೇರಿದ ಫೈಲ್ಗಳಿಗೆ ಮಾತ್ರ ಬರೆಯುತ್ತದೆ. ಪ್ರತಿ ಬ್ರಾಂಚ್ಗೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಹಂಚಿಕೊಳ್ಳಲಾದ ಕೇವಲ ಒಂದು ಫೈಲ್ ಮಾತ್ರ ಅನುಮತಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದು “last-writer-wins” ನಿಯಮವನ್ನು ಅನುಸರಿಸುತ್ತದೆ—ಅಂದರೆ ಕೊನೆಯದಾಗಿ ಬರೆಯುವ ಏಜೆಂಟ್ನ ಮಾಹಿತಿಯೇ ಅಂತಿಮವಾಗಿರುತ್ತದೆ.
ಒಂದು presence layer ಪ್ರತಿಯೊಂದು ಸಕ್ರಿಯ ಸೆಷನ್ ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ:
- ಬ್ರಾಂಚ್ ಹೆಸರು (Branch name)
- ಬಳಸಲಾಗುತ್ತಿರುವ ಫೈಲ್ಗಳ ಪಟ್ಟಿ
- ಕೊನೆಯ ಚಟುವಟಿಕೆಯ ಸಮಯ (Timestamp)
ಹೊಸ ಸೆಷನ್ ಪ್ರಾರಂಭವಾದಾಗ, ಅದು ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಒಂದು ವೇಳೆ ಮತ್ತೊಂದು ಸೆಷನ್ ಈಗಾಗಲೇ ಅದೇ ಫೈಲ್ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ಯಾವುದೇ ಕೆಲಸ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲೇ ಡೆವಲಪರ್ಗೆ ಎಚ್ಚರಿಕೆ ನೀಡಲಾಗುತ್ತದೆ.
Advisory vs. blocking locks
ಸಾಂಪ್ರದಾಯಿಕ ಲಾಕ್ ಫೈಲ್ಗಳು ಮುಗಿದುಹೋದ ರಸ್ತೆಯಂತೆ (dead-end road) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ: ಒಮ್ಮೆ ಲಾಕ್ ಪಡೆದ ನಂತರ, ಲಾಕ್ ಬಿಡುಗಡೆಯಾಗುವವರೆಗೆ ಯಾವುದೇ ಇತರ ಪ್ರಕ್ರಿಯೆಯು ಕಾಯಬೇಕಾಗುತ್ತದೆ. ಒಂದು ವೇಳೆ ಆ ಸೆಷನ್ ಕ್ರ್ಯಾಶ್ ಆದರೆ, ಲಾಕ್ ಅನಿರ್ದಿಷ್ಟಕಾಲದವರೆಗೆ ಉಳಿದುಬಿಡಬಹುದು, ಇದರಿಂದ ಹಳೆಯ ಲಾಕ್ ಫೈಲ್ಗಳನ್ನು ಹುಡುಕಲು ಮ್ಯಾನುಯಲ್ ಕೆಲಸ ಮಾಡಬೇಕಾಗುತ್ತದೆ.
Advisory ಮಾದರಿಯು ಹೆಚ್ಚು ಸುಗಮವಾಗಿದೆ. ಇದು ಸಂಭಾವ್ಯ ಸಂಘರ್ಷ ಪತ್ತೆಯಾದಾಗ ಎಚ್ಚರಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ ಆದರೆ ಹೊಸ ಸೆಷನ್ ಅನ್ನು ತಡೆಯುವುದಿಲ್ಲ. ಒಂದು ವೇಳೆ ರಿಜಿಸ್ಟ್ರಿ ಎಂಟ್ರಿ ಹಳೆಯದಾಗಿದ್ದರೆ—ಅಂದರೆ ಅದನ್ನು ರಚಿಸಿದ ಪ್ರಕ್ರಿಯೆಯು ಈಗ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದಿದ್ದರೆ—ಸಿಸ್ಟಮ್ ಕೇವಲ ಎಚ್ಚರಿಕೆ ನೀಡುತ್ತದೆ, ಮುಂದುವರಿಯಬೇಕೆ ಅಥವಾ ಬೇಡವೇ ಎಂಬುದನ್ನು ಡೆವಲಪರ್ಗಳೇ ನಿರ್ಧರಿಸಬಹುದು.
ಈ ಮಾದರಿಯನ್ನು ಹೇಗೆ ಅನುಷ್ಠಾನಗೊಳಿಸುವುದು
- ಬರಹಗಾರರ ಆಧಾರದ ಮೇಲೆ ಸ್ಟೇಟ್ ಅನ್ನು ವಿಂಗಡಿಸಿ (Partition state by writer) – ಪ್ರತಿಯೊಂದು ಏಜೆಂಟ್ಗೆ ತಾತ್ಕಾಲಿಕ ಫೈಲ್ಗಳು ಮತ್ತು ಸ್ಟೇಟ್ಗಾಗಿ ತನ್ನದೇ ಆದ ಡೈರೆಕ್ಟರಿಯನ್ನು ನೀಡಿ. ಕೇವಲ ಜಾಗತಿಕ ಡೇಟಾ (global data) ಗಾಗಿ ಹಂಚಿಕೆಯ ಫೈಲ್ಗಳನ್ನು ಮೀಸಲಿರಿಸಿ ಮತ್ತು ಅಲ್ಲಿ ಮಾತ್ರ “last-writer-wins” ನಿಯಮವನ್ನು ಅನ್ವಯಿಸಿ.
- ಪ್ರಾರಂಭದ ಹಂತದಲ್ಲೇ ಅರಿವು ಮೂಡಿಸಿ (Inject awareness at launch) – ಏಜೆಂಟ್ ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, presence registry ಅನ್ನು ಓದಿ ಮತ್ತು ಕೇಳಲಾದ ಫೈಲ್ ಪಟ್ಟಿಯನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಎಂಟ್ರಿಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ. ಅತಿಕ್ರಮಣ ಕಂಡುಬಂದಲ್ಲಿ ಕೆಲಸವನ್ನು ನಿಲ್ಲಿಸಿ ಅಥವಾ ಎಚ್ಚರಿಕೆ ನೀಡಿ.
- ಓದುವಾಗ ಲೈವ್ನೆಸ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ (Verify liveness at read time) – ರಿಜಿಸ್ಟ್ರಿ ಎಂಟ್ರಿಯನ್ನು ಪರಿಶೀಲಿಸುವಾಗ, ದಾಖಲಾದ ಪ್ರೊಸೆಸ್ ಐಡಿ (process ID) ಇನ್ನೂ OS ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿದೆಯೇ ಎಂದು ಪರೀಕ್ಷಿಸಿ. ಸತ್ತ ಪ್ರೊಸೆಸ್ಗಳಿಗೆ ಸೇರಿದ ಎಂಟ್ರಿಗಳನ್ನು ಕೈಬಿಡಿ.
- Blocking ಗಿಂತ Advisory ಗೆ ಆದ್ಯತೆ ನೀಡಿ – ಡೆವಲಪರ್ಗಳು ನಿಯಂತ್ರಣವನ್ನು ಹೊಂದಿರಲಿ. ಎಚ್ಚರಿಕೆಯು ಅವರು ಮುಂದುವರಿಯಲು, ನಿಲ್ಲಿಸಲು ಅಥವಾ ರದ್ದುಗೊಳಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಇದರಿಂದ ડેಡ್ಲಾಕ್ (deadlock) ತಪ್ಪಿಸಬಹುದು.
- ಕಾಯುತ್ತಿರುವ ಸ್ಥಿತಿಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ (Track waiting states) – ಅನೇಕ ಏಜೆಂಟ್ಗಳು ಸಕ್ರಿಯವಾಗಿದ್ದಾಗ, ಡೆವಲಪರ್ನ ಗಮನವೇ ಅಡಚಣೆಯಾಗುತ್ತದೆ (bottleneck). ಯಾವ ಏಜೆಂಟ್ಗಳು ಮಾನವನ ಇನ್ಪುಟ್ಗಾಗಿ ಕಾಯುತ್ತಿವೆ ಎಂಬುದನ್ನು ತೋರಿಸಿ, ಇದರಿಂದ ಕೆಲಸಕ್ಕೆ ಆದ್ಯತೆ ನೀಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಇವೆಲ್ಲವನ್ನೂ ಕೇವಲ JSON ಫೈಲ್ಗಳ ಡೈರೆಕ್ಟರಿಯೊಂದಿಗೆ ನಿರ್ಮಿಸಬಹುದು; ಇದಕ್ಕೆ ಯಾವುದೇ ಬಾಹ್ಯ ಡೇಟಾಬೇಸ್ ಅಥವಾ ಮೆಸೇಜ್ ಬಸ್ ಅಗತ್ಯವಿಲ್ಲ. ಸರಳವಾದ ಸ್ಟೋರೇಜ್ ಫಾರ್ಮ್ಯಾಟ್ ಈ ಸಿಸ್ಟಮ್ ಅನ್ನು ಆಡಿಟ್ ಮಾಡಲು ಸುಲಭವಾಗಿಸುತ್ತದೆ ಮತ್ತು ವಿವಿಧ ಎನ್ವಿರಾನ್ಮೆಂಟ್ಗಳಲ್ಲಿ ಸುಲಭವಾಗಿ ಬಳಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
ಅಪಾಯಗಳು ಮತ್ತು ವಿರೋಧಾಭಾಸಗಳು
ಹಾರ್ಡ್ ಲಾಕ್ ಸುರಕ್ಷತೆಯನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ ಎಂದು ಕೆಲವು ತಂಡಗಳು ವಾದಿಸಬಹುದು: ಯಾವುದೇ ಎರಡು ಏಜೆಂಟ್ಗಳು ಒಂದೇ ಫೈಲ್ಗೆ ಬರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಆದರೆ ಇದರ ಬೆಲೆ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವದ (resilience) ಇಳಿಕೆಯಾಗಿದೆ—ಕ್ರ್ಯಾಶ್ ಆದ ಸೆಷನ್ಗಳು ಅನಾಥ ಲಾಕ್ಗಳನ್ನು (orphaned locks) ಬಿಟ್ಟುಹೋಗುತ್ತವೆ, ಇದು ಇಡೀ ವರ್ಕ್ಫ್ಲೋ ಅನ್ನು ಸ್ಥಗಿತಗೊಳಿಸುತ್ತದೆ.
ಗಮನಿಸಬೇಕಾದ ಅಂಶಗಳು
ನೀವು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು AI-ಚಾಲಿತ ಕೋಡಿಂಗ್ ಅಸಿಸ್ಟೆಂಟ್ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, “share nothing” advisory ಮಾದರಿಯು ಅವುಗಳು ಒಂದಕ್ಕೊಂದು ಅಡ್ಡ ಬರದಂತೆ ತಡೆಯಲು ಒಂದು ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ. ಸ್ಟೇಟ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸುವ ಮೂಲಕ, ಉದ್ದೇಶವನ್ನು ಮೊದಲೇ ತಿಳಿಸುವ ಮೂಲಕ ಮತ್ತು ಮುಂದುವರಿಯುವ ಬಗ್ಗೆ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳಲು ಮನುಷ್ಯರಿಗೆ ಅವಕಾಶ ನೀಡುವ ಮೂಲಕ, ಈ ವಿಧಾನವು ಆಧುನಿಕ ಡೆವಲಪ್ಮೆಂಟ್ ಪೈಪ್ಲೈನ್ಗಳಿಗೆ ಅಗತ್ಯವಿರುವ ನಮ್ಯತೆ (flexibility) ಮತ್ತು ಸುರಕ್ಷತೆಯ ನಡುವೆ ಸಮತೋಲನವನ್ನು ಕಾಯ್ದುಕೊಳ್ಳುತ್ತದೆ.