使用的第三方表單程式。兩條相同資料提交時相差101毫秒。都被資料庫存了進去。查重規則沒生效。第三方公司說是相差時間間隔太小了。系統來不及識別。我不知道對方說的對不對。請大家幫助詳細說說。謝謝。
uj5u.com熱心網友回復:
資料庫是不可能識別不了的,別說101ms,0.1ms都能給你揪出來,除非——觸發了大大大大BUG。看來是應用程式實作了資料的唯一,而不是資料庫中的主鍵或者唯一索引?這程式問題看來不小了,第三方公司不敢背鍋了~
uj5u.com熱心網友回復:
查重規則沒生效。這個查詢規則,顯然是在后臺服務中做的檢查。
一般來說,造成這個情況的原因的流程大概如下:
表單的有一個提交按鈕,點了一次,沒有反應(或是網頁還沒來得及跳轉),又點了一下,這樣就會造成提交了兩次,也就是呼叫了兩次后臺服務
查重規則的定義在后臺服務中
1、第一次提交后,先去查重規則,未發現重復資料。
2、第二次提交又上來了,也去執行查重規則,也未發現重復資料。
3、寫入第一條資料
4、寫入第二條資料。
而實際上你的預期是,執行 1324, 這個順序 。
但是,第二次查重之前,第一次的資料并沒有入庫,現在,問題基本形成。
(上述,第 3 和 第4 的順序互換,也會是樣的情況)
所以,站在資料庫的角度,建議在資料庫上做一個唯一性約束(索引)來保證資料的唯一性。
uj5u.com熱心網友回復:
但是這兩條資料提交都是不同人,用手機提交的。因為設定的身份證號查重。但是沒效果。兩條相同身份證資訊都進入來了。第三方說是間隔101毫秒的問題。
uj5u.com熱心網友回復:
謝謝。懇請解釋一下應用程式實作了資料唯一和資料庫中的主鍵或者唯一索引是什么意思。
uj5u.com熱心網友回復:
意思是:如果是資料庫端使用主鍵或者唯一索引來保證資料唯一,那么就不可能出現資料重復,現在之所以出現資料重復,是程式的問題,和資料庫無關,沒有什么毫秒時間差之類的。
uj5u.com熱心網友回復:
查重規則沒生效。
這個查詢規則,顯然是在后臺服務中做的檢查。
一般來說,造成這個情況的原因的流程大概如下:
表單的有一個提交按鈕,點了一次,沒有反應(或是網頁還沒來得及跳轉),又點了一下,這樣就會造成提交了兩次,也就是呼叫了兩次后臺服務
查重規則的定義在后臺服務中
1、第一次提交后,先去查重規則,未發現重復資料。
2、第二次提交又上來了,也去執行查重規則,也未發現重復資料。
3、寫入第一條資料
4、寫入第二條資料。
而實際上你的預期是,執行 1324, 這個順序 。
但是,第二次查重之前,第一次的資料并沒有入庫,現在,問題基本形成。
(上述,第 3 和 第4 的順序互換,也會是樣的情況)
所以,站在資料庫的角度,建議在資料庫上做一個唯一性約束(索引)來保證資料的唯一性。
但是這兩條資料提交都是不同人,用手機提交的。因為設定的身份證號查重。但是沒效果。兩條相同身份證資訊都進入來了。第三方說是間隔101毫秒的問題。
不同的提交,更適用于,我說的那 1234 這個順序了。
uj5u.com熱心網友回復:
簡單的說你們第三方公司瞎扯,出現了重大的BUG。uj5u.com熱心網友回復:
資料庫表有主鍵的話,就不會有這種問題了。設計有問題。uj5u.com熱心網友回復:
可以設定主鍵啥!延遲的這個問題,是可以通過設計來避免的!uj5u.com熱心網友回復:
查重規則沒生效。
這個查詢規則,顯然是在后臺服務中做的檢查。
一般來說,造成這個情況的原因的流程大概如下:
表單的有一個提交按鈕,點了一次,沒有反應(或是網頁還沒來得及跳轉),又點了一下,這樣就會造成提交了兩次,也就是呼叫了兩次后臺服務
查重規則的定義在后臺服務中
1、第一次提交后,先去查重規則,未發現重復資料。
2、第二次提交又上來了,也去執行查重規則,也未發現重復資料。
3、寫入第一條資料
4、寫入第二條資料。
而實際上你的預期是,執行 1324, 這個順序 。
但是,第二次查重之前,第一次的資料并沒有入庫,現在,問題基本形成。
(上述,第 3 和 第4 的順序互換,也會是樣的情況)
所以,站在資料庫的角度,建議在資料庫上做一個唯一性約束(索引)來保證資料的唯一性。
但是這兩條資料提交都是不同人,用手機提交的。因為設定的身份證號查重。但是沒效果。兩條相同身份證資訊都進入來了。第三方說是間隔101毫秒的問題。
資料庫表沒有做唯一約束,這都能甩給時間差
uj5u.com熱心網友回復:
為什么沒做冪等校驗?轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/38336.html
標籤:開發
上一篇:Oracle
