在搞基於DB2的嵌入式C語言項目時,出現了一件非常奇怪的事情,拿出來與大家分享。
當時為了保持測試數據的完整性及開發人員的數據的一致性,更是為了減少DBServer的壓力,故而為每兩人做一個DB實例噩夢由此開始。
每當擔當者A編譯好程序,開始運行的之後,使用同一DB實例的擔當者B也開始編譯運行,此時擔當者A就會報出“SQL0818N A timestamp conflict occurred.”之類的錯誤。於是,A開始重新預編譯,運行,ok,開始測試,而此時的B就會報出剛才A報出的錯誤。
當時,由於剛剛接觸DB2,對其嵌入式開發還不太熟悉其原理,我自己還以為是DB2處了問題或者客戶端出了問題,於是,卸載Quest Central,重新安裝DB2。一直沒有解決問題。
後來,通過查找資料,總結,終於找出其緣由。下圖是創建包的過程。
由於只使用了段條目來標識應用程序中的上下文,修改過的源文件和包被緊緊地鏈接在一起,並且必須保證它們總是指向相同的上下文。這是通過在修改過的源文件中嵌入一個一致性標志(token),也叫“時間戳(timestamp)”,並且在 DB2UDB 內將相同的值存儲在包信息中來實現的。來自應用程序的每一條請求都帶有這種一致性標志,傳入的值要與編目表中的值相比較。如果這兩個值不相同,並且裝入模塊的時間戳與一致性標志不相同,那麼將發生一個“timestamp”錯誤(SQLCODE -818)。
原因就是如上所述,希望對你有用。