ಬಳಕೆದಾರರು 'ಸೇಂಡ್' ಬಟನ್ ಅನ್ನು ಪದೇ ಪದೇ ಒತ್ತಿದಾಗ, ಬಾಟ್ ಒಂದೇ ಉತ್ತರವನ್ನು ಎರಡು ಅಥವಾ ಮೂರು ಬಾರಿ ನೀಡಲು ಪ್ರಾರಂಭಿಸಿತು. AI ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲೇ ಬಳಕೆದಾರರು ವೇಗವಾಗಿ ಹಲವಾರು ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸಿದಾಗ ಮಾತ್ರ ಈ ಪುನರಾವರ್ತನೆ ಕಂಡುಬರುತ್ತಿತ್ತು, ಮತ್ತು ಈ ಮಾದರಿಯು ಅಪರೂಪದ ಘಟನೆಯಾಗಿದ್ದರಿಂದ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಬಹಳ ಕಾಲ ಅಡಗಿದ್ದಿತು. ಡೇಟಾಬೇಸ್ ಲಾಕ್ ಅನ್ನು ಅಲ್ಪ ಸಮಯದ ನಂತರವೇ ಬಿಡುಗಡೆ ಮಾಡಿದ್ದರಿಂದ, ಸಂಭಾಷಣೆಯು ರಕ್ಷಣೆ ಇಲ್ಲದಂತಾಯಿತು ಮತ್ತು ಒಂದೇ ಪ್ರಾಂಪ್ಟ್ಗೆ ಹಲವಾರು ಪ್ರಕ್ರಿಯೆಗಳು ಉತ್ತರಿಸಲು ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು.
ಲಾಕ್ ಏಕೆ ವಿಫಲವಾಯಿತು
ಕೋಡ್ ಒಂದೇ ಡೇಟಾಬೇಸ್ ಕರೆಯಲ್ಲಿ ಲಾಕ್ ಅನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತದೆ, ನಂತರ ತಕ್ಷಣವೇ ನಿಯಂತ್ರಣವನ್ನು ರಿಕ್ವೆಸ್ಟ್ ಹ್ಯಾಂಡ್ಲರ್ಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಲಾಕ್ನ ಅವಧಿಯು ಮಿಲಿಸೆಕೆಂಡುಗಳಲ್ಲಿತ್ತು, ಇದು AI ಮಾಡೆಲ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸಿದ್ಧಪಡಿಸಲು ಬೇಕಾದ ಸಮಯಕ್ಕಿಂತ ಬಹಳ ಕಡಿಮೆ ಇತ್ತು. ಮಾಡೆಲ್ ಕೆಲಸ ಪ್ರಾರಂಭಿಸುವಷ್ಟರಲ್ಲಿ, ಲಾಕ್ ಈಗಾಗಲೇ ಇಲ್ಲದಂತಾಗಿತ್ತು, ಆದ್ದರಿಂದ ಎರಡನೇ ರಿಕ್ವೆಸ್ಟ್ ಅದೇ ಸಂಭಾಷಣೆಯ ರೆಕಾರ್ಡ್ ಅನ್ನು ಪಡೆದು ಮತ್ತೊಂದು ಉತ್ತರವನ್ನು ನೀಡದಂತೆ ತಡೆಯಲು ಏನೂ ಇರಲಿಲ್ಲ.
ಎರಡು ಲಕ್ಷಣಗಳು ಕಂಡುಬಂದವು:
- ಒಂದೇ ರೀತಿಯ ಉತ್ತರಗಳು ಸತತವಾಗಿ ಕಳುಹಿಸಲ್ಪಟ್ಟವು.
- ಒಂದೇ ಪ್ರಶ್ನೆಗೆ ಸ್ವಲ್ಪ ಮರುರೂಪಿಸಿದ ಉತ್ತರಗಳು ಕಾಣಿಸಿಕೊಂಡವು, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದು ಪ್ರಕ್ರಿಯೆಯು ಒಂದೇ ಬಳಕೆದಾರ ಇನ್ಪುಟ್ನಿಂದ ತನ್ನದೇ ಆದ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿತ್ತು.
ಹೆಚ್ಚಿನ ಬಳಕೆದಾರರು ಸಂದೇಶಗಳ ನಡುವೆ ವಿರಾಮ ತೆಗೆದುಕೊಳ್ಳುವುದರಿಂದ, ಈ ಬಗ್ ಗಮನಕ್ಕೆ ಬರದೇ ಇತ್ತು. ಕೇವಲ ವೇಗವಾಗಿ ಟೈಪ್ ಮಾಡುವವರು ಮಾತ್ರ ರೇಸ್ ಕಂಡೀಷನ್ (race condition) ಅನ್ನು ಉಂಟುಮಾಡುತ್ತಿದ್ದರು ಮತ್ತು ಅಂತಹ ಪ್ರಕರಣಗಳು ಅಪರೂಪವಾಗಿದ್ದವು.
ಅರೆಬರೆ ಪರಿಹಾರವು ಕೆಲಸ ಮಾಡಲಿಲ್ಲ
ಮೊದಲ ಪ್ರತಿಕ್ರಿಯೆಯೆಂದರೆ, ವೇಗವಾದ ಇನ್ಪುಟ್ ಅನ್ನು "ಡಿಬೌನ್ಸ್" (debounce) ಮಾಡಲು ಸಂದೇಶ ಬಂದ ನಂತರ ಒಂದು ಸಣ್ಣ ವಿಳಂಬವನ್ನು ಸೇರಿಸುವುದು. ಇದು ಎರಡು ಸಂದೇಶಗಳು ವೇಗವಾಗಿ ಬಂದಾಗ ಸಹಾಯ ಮಾಡಿತು, ಆದರೆ AI ಪಠ್ಯವನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತಿರುವಾಗಲೇ ಮೂರನೇ ಸಂದೇಶ ಬಂದಲ್ಲಿ ಇದು ವಿಫಲವಾಯಿತು.
ಟೈಮರ್ಗಳು ಮತ್ತು ಸಂಭಾಷಣೆಯ ಡೇಟಾ ಒಂದೇ ಸ್ಟೋರೇಜ್ ಬಕೆಟ್ನಲ್ಲಿ ಇದ್ದಾಗ ಎರಡನೇ ಸಮಸ್ಯೆ ಎದುರಾಯಿತು. ಬಾಟ್ ಒಂದು ರಿಕ್ವೆಸ್ಟ್ ಅನ್ನು ಪ್ರೊಸೆಸ್ ಮಾಡಿದ ನಂತರ, ಅದು ಟೈಮರ್ ರೆಕಾರ್ಡ್ ಅನ್ನು ಓವರ್ರೈಟ್ ಮಾಡಿತು, ಇದರಿಂದಾಗಿ ತನ್ನದೇ ಆದ ಕೌಂಟ್ಡೌನ್ ಅನ್ನು ಅಳಿಸಿಹಾಕಿತು. ಸಿಸ್ಟಮ್ ಯಾವ ಸಂದೇಶಗಳಿಗೆ ಈಗಾಗಲೇ ಉತ್ತರಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಾಗದೆ, ಮತ್ತಷ್ಟು ಪುನರಾವರ್ತನೆಗೆ ದಾರಿ ಮಾಡಿಕೊಟ್ಟಿತು.
ನಂಬಿಕಸ್ತ ರಕ್ಷಣೆ ನಿರ್ಮಿಸುವುದು: ವರ್ಷನ್ ಕೌಂಟರ್ಗಳು, ಪ್ರತ್ಯೇಕ ಟೈಮರ್ಗಳು ಮತ್ತು ಲೀಸ್
ತಂಡವು ಮೂರು ಪ್ರಮುಖ ಅಂಶಗಳ ಸುತ್ತ ಹರಿವನ್ನು ಮರು ವಿನ್ಯಾಸಗೊಳಿಸಿತು:
- ವರ್ಷನ್ ಕೌಂಟರ್ (Version counter) – ಪ್ರತಿ ಬಂದ ಸಂದೇಶವು ಸಂಭಾಷಣೆಯೊಂದಿಗೆ ಸಂಗ್ರಹಿಸಲಾದ ಕೌಂಟರ್ ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಪ್ರತಿಕ್ರಿಯೆ ಸಿದ್ಧವಾಗುತ್ತಿರುವಾಗ ಹೊಸ ಇನ್ಪುಟ್ ಅನ್ನು ಸುಲಭವಾಗಿ ಪತ್ತೆಹಚ್ಚಲು ಈ ಕೌಂಟರ್ ಸಿಸ್ಟಮ್ಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.
- ಸಮರ್ಪಿತ ಡಿಬೌನ್ಸ್ ವಿಂಡೋ (Dedicated debounce window) – ಟೈಮರ್ಗಳು ಈಗ ಸಂಭಾಷಣೆಯ ಪೇಲೋಡ್ಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾದ ಸ್ಟೋರೇಜ್ ಪ್ರದೇಶದಲ್ಲಿ ಇರುತ್ತವೆ. ಡಿಬೌನ್ಸ್ ಅವಧಿಯ ಮೇಲೆ ಕಟ್ಟುನಿಟ್ಟಿನ ಮಿತಿ ಇರುವುದರಿಂದ ಬಳಕೆದಾರರು ಬಾಟ್ ಅನ್ನು ಅನಗತ್ಯವಾಗಿ ತಡೆಹಿಡಿಯುವುದನ್ನು ತಡೆಯಬಹುದು.
- ಸೆಷನ್ ಲೀಸ್ (Session lease) – ಮೂಲ ಲಾಕ್ ಅನ್ನು ಒಂದು 'ಲೀಸ್' (lease) ಮೂಲಕ ಬದಲಾಯಿಸಲಾಗಿದೆ, ಇದು ಸ್ಪಷ್ಟವಾದ ಅವಧಿ ಮುಕ್ತಾಯದ ಸಮಯವನ್ನು (expiry timestamp) ಹೊಂದಿರುತ್ತದೆ. ಲೀಸ್ ಅನ್ನು
compare-and-swap (CAS)ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಬಳಸಿ ಪಡೆಯಲಾಗುತ್ತದೆ: ಪ್ರಕ್ರಿಯೆಯು ಪ್ರಸ್ತುತ ಲೀಸ್ ಮೌಲ್ಯವನ್ನು ಓದುತ್ತದೆ, ಹಳೆಯ ಮೌಲ್ಯವು ಹೊಂದಿಕೆಯಾದರೆ ಮಾತ್ರ ಹೊಸ ಮೌಲ್ಯವನ್ನು ಬರೆಯುತ್ತದೆ, ಮತ್ತು ಈ ಮೂಲಕ ಸಂಭಾಷಣೆಯ ಮೇಲೆ ವಿಶೇಷ ಹಕ್ಕನ್ನು ಪಡೆಯುತ್ತದೆ. ಒಂದು ವೇಳೆ ಪ್ರಕ್ರಿಯೆಯು ಕ್ರ್ಯಾಶ್ ಆಗಿದರೆ, ಲೀಸ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅವಧಿ ಮುಗಿದು, ಮುಂದಿನ ಹ್ಯಾಂಡ್ಲರ್ಗಾಗಿ ಸಂಭಾಷಣೆಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತದೆ.
ಹೊಸ ಪೈಪ್ಲೈನ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ
- ಸಂದೇಶದ ಆಗಮನ – ಸಿಸ್ಟಮ್ ವರ್ಷನ್ ಕೌಂಟರ್ ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಮತ್ತು ಡಿಬೌನ್ಸ್ ಟೈಮರ್ ಅನ್ನು (ಮರು)ಸೆಟ್ ಮಾಡುತ್ತದೆ. ಇದು AI ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲೇ ತಕ್ಷಣವೇ ಕ್ಲೈಂಟ್ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ.
- ಟೈಮರ್ ಅವಧಿ ಮುಕ್ತಾಯ – ಟೈಮರ್ ಹ್ಯಾಂಡ್ಲರ್ ಲೀಸ್ ಅನ್ನು ಪಡೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. CAS ಯಶಸ್ವಿಯಾದರೆ, ಹ್ಯಾಂಡ್ಲರ್ ಮುಂದುವರಿಯುತ್ತದೆ; ಇಲ್ಲದಿದ್ದರೆ, ಮತ್ತೊಂದು ಪ್ರಕ್ರಿಯೆಯು ಈಗಾಗಲೇ ಸಂಭಾಷಣೆಯನ್ನು ಹೊಂದಿದೆಯೇ ಎಂದು ತಿಳಿದು ಅದು ಹಿಂದೆ ಸರಿಯುತ್ತದೆ.
- ಹೊಸ ಇನ್ಪುಟ್ ಪರಿಶೀಲನೆ – ಹ್ಯಾಂಡ್ಲರ್ ಪ್ರಸ್ತುತ ವರ್ಷನ್ ಕೌಂಟರ್ ಅನ್ನು ಟೈಮರ್ ಪ್ರಾರಂಭಿಸಿದಾಗ ದಾಖಲಿಸಿದ ಮೌಲ್ಯದೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ. ಕೌಂಟರ್ ಹೆಚ್ಚಾಗಿದ್ದರೆ, ಅದು ಬಾಕಿ ಇರುವ ಸಂದೇಶಗಳನ್ನು ಒಂದೇ ಪ್ರಾಂಪ್ಟ್ಗೆ ಒಟ್ಟುಗೂಡಿಸುತ್ತದೆ.
- ಉತ್ತರವನ್ನು ಸಿದ್ಧಪಡಿಸುವುದು – AI ಮಾಡೆಲ್ ಒಮ್ಮೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು ಎಲ್ಲಾ ಇತ್ತೀಚಿನ ಬಳಕೆದಾರ ಇನ್ಪುಟ್ಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಒಂದೇ ಉತ್ತರವನ್ನು ನೀಡುತ್ತದೆ.
- ಅಂತಿಮ ಪರಿಶೀಲನೆ (Final sanity check) – ಉತ್ತರವನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು, ಹ್ಯಾಂಡ್ಲರ್ ಮತ್ತೊಮ್ಮೆ ವರ್ಷನ್ ಕೌಂಟರ್ ಅನ್ನು ಓದುತ್ತದೆ. ಜನರೇಷನ್ ಸಮಯದಲ್ಲಿ ಹೊಸ ಸಂದೇಶ ಬಂದಿದ್ದರೆ, ಉತ್ತರವನ್ನು ರದ್ದುಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯು ಟೈಮರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಇದರಿಂದ ಯಾವುದೇ ಹಳೆಯ ಅಥವಾ ಅಪ್ರಸ್ತುತ ಉತ್ತರ ಬಳಕೆದಾರರಿಗೆ ತಲುಪದಂತೆ ಖಚಿತಪಡಿಸುತ್ತದೆ.
ಈ ವಿಧಾನವು ಪುನರಾವರ್ತಿತ ಉತ್ತರಗಳನ್ನು ನಿವಾರಿಸುತ್ತದೆ, ಸಂಭಾಷಣೆಯು ತಡೆಹಿಡಿಯಲ್ಪಡುವ ಸಮಯವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ ಮತ್ತು ಲೀಸ್ ತನ್ನಷ್ಟಕ್ಕೆ ತಾನೇ ಅವಧಿ ಮುಗಿಯುವುದರಿಂದ ಪ್ರಕ್ರಿಯೆಯ ಕ್ರ್ಯಾಶ್ಗಳಿಂದ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಚೇತರಿಸಿಕೊಳ್ಳುತ್ತದೆ.
ಸಾರಾಂಶ
ಕ್ರಿಟಿಕಲ್ ಸೆಕ್ಷನ್ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲೇ ಮಾಯವಾಗುವ ಲಾಕ್ ಯಾವುದೇ ರಕ್ಷಣೆಯನ್ನು ನೀಡುವುದಿಲ್ಲ. ಕ್ಷಣಿಕ ಡೇಟಾಬೇಸ್ ಲಾಕ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾದ, ಅವಧಿ ಮುಕ್ತಾಯಗೊಳ್ಳುವ ಲೀಸ್ ಮೂಲಕ ಬದಲಾಯಿಸುವ ಮೂಲಕ ಮತ್ತು ಟೈಮರ್ಗಳನ್ನು ಸಂಭಾಷಣೆಯ ಡೇಟಾದಿಂದ ಪ್ರತ್ಯೇಕಿಸುವ ಮೂಲಕ, ಬಳಕೆದಾರರು ಮಿಂಚಿನ ವೇಗದಲ್ಲಿ ಟೈಪ್ ಮಾಡಿದಾಗಲೂ ಬಾಟ್ ಈಗ ಒಂದೇ, ಅಪ್-ಟು-ಡೇಟ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಈ ಘಟನೆಯು ಒಂದು ಶಾಶ್ವತ ಪಾಠವನ್ನು ಒತ್ತಿಹೇಳುತ್ತದೆ: ಕನ್ಕರನ್ಸಿ ಸುರಕ್ಷತಾ ಕ್ರಮಗಳು (concurrency safeguards) ಅವು ರಕ್ಷಿಸುವ ಕೆಲಸಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಅವು ಬಗ್ಗಳು ಜಾರಿಕೊಳ್ಳಲು ಬಿಡುವ ಅದೃಶ್ಯ ಅಡೆತಡೆಗಳಾಗುತ್ತವೆ.