מניעת race condition ב-DB

avr416

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

אני מממש דבר כזה בחנות אינטרנטית, כשיש צורך להגביל מוצר לפי כמות במלאי, ואני לא רוצה שיווצר מצב דומה למה שתיארת.

yossiz

@chagold אבל הקוד הפנימי של ה-DB שמממש את זה לא זמין לנו המשתמשים.

chagold

@yossiz https://www.postgresql.org/docs/9.3/sourcerepo.html?

yossiz

@chagold אני יודע שקוד המקור של ה-DB זמין, אבל מה אני אעשה עם זה?
אני לא הולך לערוך את הקוד ולקמפל כדי להוסיף אפשרות זו.

chagold

פוסט זה נמחק!

yossiz

@yossiz אמר במניעת race condition ב-DB:

לעשות את כל התהליך בפקודת SQL אחד.

@dovid אמר במניעת race condition ב-DB:

אני יודע שבSQL SERVER נכון להיום אתה מוגן ב4

אתה בטוח בזה? יש לך מקור?

@clickone אמר במניעת race condition ב-DB:

לכאורה בשיטה הזו הוא ינעל את השינויים כי זה נעשה בפעם אחת

מכיון שהנושא מאוד סקרן אותי והתחלתי לחשוש שזה לא נכון עשיתי נסיון,

יצרתי טבלה פשוטה:

create table test (id  SERIAL, i INTEGER);

ואז הרצתי בלולאה במקביל בשתי סשנים את הפקודה הזאת:

INSERT INTO
    test (i)
VALUES
    (
        (SELECT max FROM (SELECT MAX(i) AS max, pg_sleep(1) FROM test) AS i) + 1
    );

(הוספתי את ה-pg_sleep כדי למקסם את הסיכויים להתנגשות)

התוצאה היתה שהיו מספר שורות עם אותו מספר, בניגוד לצפיה שכל שורה תהיה מספר אחד מעל לשורה הקודמת, כלומר שהיה race condition.
אח"כ שניתי את הפרמטרים של הקליינטים:

SET default_transaction_isolation TO serializable;

והרצתי את זה שוב, וחלק מהפעולות נכשלו בגלל התנגשויות

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

אני חושש שזה המצב בכל המנועים ואם כן זו נקודה חשובה להיות מודע לזה.

dovid

@yossiz אמר במניעת race condition ב-DB:

אתה בטוח בזה? יש לך מקור?

כעת בדקתי, זה לא נכון (נוצר לי כפילות..) אז אני לא מחפש מקור
מהלינקים שהבאתי כבר למעלה עולה שחובה לעשות נעילה ברמת SERIALIZABLE בדיוק כפי שכתבת.
יש פתרון פה לא הבנתי אותו, מריצים את זה באותו פקודה של ההכנסה?
סתם ככה אשמח לדעת מה הרקע של הצורך.

yossiz

@dovid אמר במניעת race condition ב-DB:

סתם ככה אשמח לדעת מה הרקע של הצורך.

אין באמת צורך כל כך חשוב, אבל אני שמח לדעת את הפתרון בלי קשר.
מדובר בטבלה של כסף שנכנס לארגון (תרומות), לצרכי תצוגה אנחנו רוצים לתת לכל charge מספר ידידותי במקום לזהות אותו על ידי ה-PK. לצורך תצוגה אנחנו מעדיפים שהמספרים של ה-charges של כל ארגון יהיו עוקפים. אנחנו רוצים גם שהמספרים יהיו קבועים, כלומר גם אם נמחק תרומה מאיזה סיבה זה לא אמור לשנות את כל המספרים.
האם זה סיבה מספקת להכריח נעילה על ה-DB לכל הכנסת תרומה? אני לא יודע... נחיה ונראה...

yossiz

@dovid אמר במניעת race condition ב-DB:

יש פתרון פה לא הבנתי אותו, מריצים את זה באותו פקודה של ההכנסה?

גם אני לא הבנתי. כנראה שהעונה לא הבין את השאלה.

clickone

@yossiz אמר במניעת race condition ב-DB:

אין באמת צורך כל כך חשוב

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

מנצפך

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

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

שאר הפתרונות שיש כאן הם ברמת הDB, ומשתנים ממנוע אחד למשנהו ואפילו מגירסה לגירסה.

yossiz

@מנצפך תודה, הפתרון שלך דומה מאוד לפתרון 3 שהצעתי, רק שאני הצעתי להשתמש בשירות מובנה של ה-DB ואתה מציע לממש את זה בעצמי.

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

לעצם הפתרון, אחרי מחשבה אני תופס שלכאורה זה הפתרון הכי זול (מבחינת נעילות) שקיים. הנעילה תהיה רק על הפעולה שחייבת נעילה.

מנצפך

לא הבנתי על מה אתה מדבר? כי בפתרון שלי אין שום מימוש של נעילה

yossiz

@מנצפך נכון, התכוונתי למצב שמגביל את הגישה לאחד אחד. זה שוה ערך לנעילה.

מנצפך

זה לא מגביל את הקליינט בשליחת בקשה כמובן. רק התשובה תתמהמה מעט.

nigun

@yossiz אמר במניעת race condition ב-DB:

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

איזה חסרונות קיימים בנעילה בקוד?
(באיזה שפה הקוד כתוב?)

dovid

@nigun בנעילה בקוד יש שתי בעיות:
א. בתחזוקת הקוד לעולם צריך לזכור את האחריות הזאת
ב. צריך לוודא שאין מצב של ריצה מקבילה של מופעים, אסור שהתוכנה תרוץ פעמיים.

yossiz

@nigun אני לא בטוח שיש שום חסרונות בנעילה בקוד. (עריכה: עיין מה שכתב דוד למעלה)
זה nodejs.

מה ש@מנצפך מציע הוא (אולי הרבה) יותר זול מנעילה בקוד.
אבל מצד שני יש חסרון שכאשר מדובר בעשרות אלפי ארגונים וצריך לשמור מספר לכל אחד זה יתפוס משאבים. וגם, צריך לכתוב את זה בצורה נכונה שהמספרים תמיד יהיו מסונכרנים עם מה שיש ב-DB. (אני לא אומר שזה קשה, רק זה עוד חחתיכת קוד שצריך לוודא שהוא פועל נכון).
אגב, @מנצפך חושב מאוד גדול... מכיון שכרגע הגישה ל-DB אצלי הוא רק על ידי תהליך אחד אין צורך בשרת נפרד שיעשה את זה, אלא אפשר לעשות את זה בתוך התהליך.

nigun

@dovid אמר במניעת race condition ב-DB:

ב. צריך לוודא שאין מצב של ריצה מקבילה של מופעים, אסור שהתוכנה תרוץ פעמיים.

מה הבעיה? ריצה מקבילה של מספר מופעים באותו אפליקציה או ריצה של מספר אפליקציות?

yossiz

@nigun הנעילה מגינה מפני מספר מופעים באותו תהליך, אבל אם יש מספר מופעים של התהליך לא תעזור הנעילה.
אבל זה לא לגמרי נכון כי זה תלוי איך עושים את הנעילה.

תחומים - פורום חרדי מקצועי

מניעת race condition ב-DB