在搞基于DB2的嵌入式C語(yǔ)言項(xiàng)目時(shí)，出現(xiàn)了一件非常奇怪的事情，拿出來(lái)與大家分享。
當(dāng)時(shí)為了保持測(cè)試數(shù)據(jù)的完整性及開(kāi)發(fā)人員的數(shù)據(jù)的一致性，更是為了減少DBServer的壓力，故而為每?jī)扇俗鲆粋€(gè)DB實(shí)例噩夢(mèng)由此開(kāi)始。
每當(dāng)擔(dān)當(dāng)者A編譯好程序，開(kāi)始運(yùn)行的之后，使用同一DB實(shí)例的擔(dān)當(dāng)者B也開(kāi)始編譯運(yùn)行，此時(shí)擔(dān)當(dāng)者A就會(huì)報(bào)出“SQL0818N A timestamp conflict occurred.”之類的錯(cuò)誤。于是，A開(kāi)始重新預(yù)編譯，運(yùn)行，ok，開(kāi)始測(cè)試，而此時(shí)的B就會(huì)報(bào)出剛才A報(bào)出的錯(cuò)誤。
當(dāng)時(shí)，由于剛剛接觸DB2，對(duì)其嵌入式開(kāi)發(fā)還不太熟悉其原理，我自己還以為是DB2處了問(wèn)題或者客戶端出了問(wèn)題，于是，卸載Quest Central,重新安裝DB2。一直沒(méi)有解決問(wèn)題。
后來(lái)，通過(guò)查找資料，總結(jié)，終于找出其緣由。下圖是創(chuàng)建包的過(guò)程。
由于只使用了段條目來(lái)標(biāo)識(shí)應(yīng)用程序中的上下文，修改過(guò)的源文件和包被緊緊地鏈接在一起，并且必須保證它們總是指向相同的上下文。這是通過(guò)在修改過(guò)的源文件中嵌入一個(gè)一致性標(biāo)志（token），也叫“時(shí)間戳（timestamp）”，并且在 DB2UDB 內(nèi)將相同的值存儲(chǔ)在包信息中來(lái)實(shí)現(xiàn)的。來(lái)自應(yīng)用程序的每一條請(qǐng)求都帶有這種一致性標(biāo)志，傳入的值要與編目表中的值相比較。如果這兩個(gè)值不相同，并且裝入模塊的時(shí)間戳與一致性標(biāo)志不相同，那么將發(fā)生一個(gè)“timestamp”錯(cuò)誤（SQLCODE -818）。
當(dāng)時(shí)為了保持測(cè)試數(shù)據(jù)的完整性及開(kāi)發(fā)人員的數(shù)據(jù)的一致性，更是為了減少DBServer的壓力，故而為每?jī)扇俗鲆粋€(gè)DB實(shí)例噩夢(mèng)由此開(kāi)始。
每當(dāng)擔(dān)當(dāng)者A編譯好程序，開(kāi)始運(yùn)行的之后，使用同一DB實(shí)例的擔(dān)當(dāng)者B也開(kāi)始編譯運(yùn)行，此時(shí)擔(dān)當(dāng)者A就會(huì)報(bào)出“SQL0818N A timestamp conflict occurred.”之類的錯(cuò)誤。于是，A開(kāi)始重新預(yù)編譯，運(yùn)行，ok，開(kāi)始測(cè)試，而此時(shí)的B就會(huì)報(bào)出剛才A報(bào)出的錯(cuò)誤。
當(dāng)時(shí)，由于剛剛接觸DB2，對(duì)其嵌入式開(kāi)發(fā)還不太熟悉其原理，我自己還以為是DB2處了問(wèn)題或者客戶端出了問(wèn)題，于是，卸載Quest Central,重新安裝DB2。一直沒(méi)有解決問(wèn)題。
后來(lái)，通過(guò)查找資料，總結(jié)，終于找出其緣由。下圖是創(chuàng)建包的過(guò)程。
由于只使用了段條目來(lái)標(biāo)識(shí)應(yīng)用程序中的上下文，修改過(guò)的源文件和包被緊緊地鏈接在一起，并且必須保證它們總是指向相同的上下文。這是通過(guò)在修改過(guò)的源文件中嵌入一個(gè)一致性標(biāo)志（token），也叫“時(shí)間戳（timestamp）”，并且在 DB2UDB 內(nèi)將相同的值存儲(chǔ)在包信息中來(lái)實(shí)現(xiàn)的。來(lái)自應(yīng)用程序的每一條請(qǐng)求都帶有這種一致性標(biāo)志，傳入的值要與編目表中的值相比較。如果這兩個(gè)值不相同，并且裝入模塊的時(shí)間戳與一致性標(biāo)志不相同，那么將發(fā)生一個(gè)“timestamp”錯(cuò)誤（SQLCODE -818）。