פתרון אמינות בין תהליכים

מספר העסקה מוקצה רק לבקשה חדשה שהתקבלה לפרסום. כאשר נמצא מזהה קיים ותוכן זהה, מחזירים את הרשומה השמורה בלי להגדיל מונה ובלי לכתוב שוב ליומן. קונפליקט תוכן מחזיר שגיאה ואינו משנה אף מפה.

ה־WAL צריך לכלול מספיק מידע לבנות מחדש את שתי המפות. אם נשמור רק key ו־value, נוכל לשחזר מצב נוכחי אבל לא לדעת שבקשה מסוימת כבר בוצעה. אם נשמור רק מזהה, לא נוכל לבדוק שה־retry מכיל את אותו תוכן.

סדר הפרסום

סדר אפשרי הוא אימות הבקשה, בניית מצב מועמד, כתיבת data ו־commit, flush, החלפת המצב בזיכרון ושליחת תשובה. בניית המועמד לפני ה־flush מונעת מצב שבו העסקה עמידה אבל הקצאה רגילה שנדרשת לעדכון המפות נכשלת אחרי האישור הפנימי.

אם התהליך קורס אחרי flush ולפני החלפת המצב, recovery ישחזר את העסקה. אם הוא קורס אחרי ההחלפה ולפני התשובה, הלקוח עדיין יכול לקבל replay. בשני המצבים אין להסתמך על המצב בזיכרון מן ההרצה הקודמת.

כשל flush משאיר מצב לא ודאי לגבי האחסון, ולכן השרת אינו ממשיך לאשר עסקאות כאילו היומן בוודאות נקי. אפשר לסיים את השירות ולבצע recovery מבוקר לפני המשך. כך לא מוסיפים רשומות אחרי סיומת שחוזה הכתיבה שלה אינו ידוע.

סיום חלון

מדיניות retention יכולה להקצות epoch ל־session ולשמור את כל מזהיו עד אישור סיום. לאחר סגירת epoch, מזהים ממנו נדחים כישנים במקום להתפרש כבקשות חדשות. הקורא צריך לדעת שאינו יכול לדרוש replay לנצח לאחר שסיים את החלון.

החלופה של מחיקה לפי גיל בלבד דורשת שהלקוח ידע את הגבול ושהשרת יוכל לזהות בקשה שחורגת ממנו. אחרת retry ישן הופך בטעות לאפקט חדש. ההבטחה נובעת מן הפרוטוקול והמצב הנשמר, ולא מהכינוי "בדיוק פעם אחת".