מניעת race condition ב-DB
-
פתרון ברמת האפליקציה:
אתה צריך כנראה לעשות שרת בעל מופע אחד שיהיה אחראי להוציא קבלות/מספרי תרומות.
תהיה רשימה שתחזיק את כל הבקשות, ובאמצעות לולאה תיקח כל פעם בקשה אחת ותטפל בה.
כך לא יהיו לעולם התנגשויות. (וכמובן תשתמש בהצעה של תת שאילתה).
אני הייתי מיישם את זה ככה.אפשר להקצות את כל השרת רק לזה, אם אתה רוצה למנוע מצבים של עומס (כי זה תהליך אחד שעושה את כל הקבלות).
שאר הפתרונות שיש כאן הם ברמת הDB, ומשתנים ממנוע אחד למשנהו ואפילו מגירסה לגירסה.
-
@מנצפך תודה, הפתרון שלך דומה מאוד לפתרון 3 שהצעתי, רק שאני הצעתי להשתמש בשירות מובנה של ה-DB ואתה מציע לממש את זה בעצמי.
אני רואה יתרונות במימוש עצמי של השירות, אבל לעומת זה אני רואה חסרונות גם כן, ובפרט בפרוייקט בגודל זה (כלומר קטן מאוד כרגע) לא נראה לי ששוה לי ההשקעה.
לעצם הפתרון, אחרי מחשבה אני תופס שלכאורה זה הפתרון הכי זול (מבחינת נעילות) שקיים. הנעילה תהיה רק על הפעולה שחייבת נעילה.
-
@nigun אני לא בטוח שיש שום חסרונות בנעילה בקוד. (עריכה: עיין מה שכתב דוד למעלה)
זה nodejs.מה ש@מנצפך מציע הוא (אולי הרבה) יותר זול מנעילה בקוד.
אבל מצד שני יש חסרון שכאשר מדובר בעשרות אלפי ארגונים וצריך לשמור מספר לכל אחד זה יתפוס משאבים. וגם, צריך לכתוב את זה בצורה נכונה שהמספרים תמיד יהיו מסונכרנים עם מה שיש ב-DB. (אני לא אומר שזה קשה, רק זה עוד חחתיכת קוד שצריך לוודא שהוא פועל נכון).
אגב, @מנצפך חושב מאוד גדול... מכיון שכרגע הגישה ל-DB אצלי הוא רק על ידי תהליך אחד אין צורך בשרת נפרד שיעשה את זה, אלא אפשר לעשות את זה בתוך התהליך.