對于ADO處理要非常的謹慎，我們的大多數(shù)beta版產(chǎn)品的質(zhì)量都同Microsoft已發(fā)布的產(chǎn)品的質(zhì)量是一樣的，只有對數(shù)據(jù)準確性要求極高并且用戶可以忍受等待的情況下，使用這種并發(fā)沖突的處理方法。

1. 放任不管方式：

與其說這是一種處理并發(fā)沖突的方式，不如說，它是一種沒有對并發(fā)沖突做任何處理的方式。但是在許多過去的系統(tǒng)里，由于沒有考慮到多用戶、網(wǎng)絡(luò)應用等情況，這種"處理方式"還真存在于不少系統(tǒng)中。

舉例來說，A、B兩人從數(shù)據(jù)庫中獲取了同一個筆記本的信息，例如：IBM ThinkPad T61吧。然后：A把牌子改成了：Lenovo ThinkPad，B把型號改成了T61 8890A24。然后，他們開始提交了。此時，如果A先提交，然后B提交，那么，最后的結(jié)果是：IBM ThinkPad T61 8890A24ADO處理；反之，則變成Lenovo ThinkPad T61。

總之一句話，誰最后提交誰老大。想像一下，如果A修改了1000個屬性的值，B修改了1個屬性的值，那么，對于先提交的A來說，這將是一個多么慘痛的打擊:-) 雖然這種放任不管的方式似乎不太負責任，但是，其處理性能卻是相對較高的。

2. 開放式并發(fā)處理

開放式并發(fā)處理，老外叫做Optimistic Concurrency——樂觀的并發(fā)。這種并發(fā)處理方式要求我們對并發(fā)抱有一種樂觀的態(tài)度：百分之九十九點九九不會發(fā)生并發(fā)沖突，萬一發(fā)生了，系統(tǒng)也能捕獲到?jīng)_突，或者根據(jù)策略自動處理，或者，就提醒一下用戶，讓用戶來決定是不是要繼續(xù)提交。

仍然用上面的例子來說這事兒：A、B兩個人同時獲取了筆記本的信息：IBM ThinkPad T61。然后……（此處跟上例做一樣的修改，直到提交）此時，如果A先提交，那么，B提交的時候，系統(tǒng)會發(fā)現(xiàn)，哎喲，不好，有并發(fā)沖突了，就會拋個異常給B，讓B知道，發(fā)生并發(fā)沖突了ADO處理，然后，B就可以根據(jù)實際情況，選擇相應的處理策略（比如，繼續(xù)提交進行覆蓋或者取消提交等等）；相反，如果B先提交，那么，A提交時，就會得到相應的提醒。 #t#

這樣的并發(fā)處理方式，可以說在可靠性與性能上取得平衡，適合于對數(shù)據(jù)可靠性要求不是特別嚴格，需要較高的性能，并且不會大量發(fā)生并發(fā)的場合。

3. 保守式并發(fā)ADO處理

這是最為嚴謹?shù)囊环N并發(fā)沖突的處理方式。它把并發(fā)轉(zhuǎn)化為了串行操作。 例如，A從數(shù)據(jù)庫中獲取了筆記本信息：IBM ThinkPad T61，B也要對其進行修改，但此時由于A已經(jīng)從數(shù)據(jù)庫中將數(shù)據(jù)取出，因此，B被置于等待狀態(tài)。直到A把數(shù)據(jù)修改完提交了，ADO處理數(shù)據(jù)庫數(shù)據(jù)更新為Lenovo ThinkPad T61了，此時，數(shù)據(jù)庫才把數(shù)據(jù)給B，那么B就可以在Lenovo ThinkPad T61的基礎(chǔ)上，把它修改為Lenovo ThinkPad T61 8890A24。而在B提交前，其它一切針對此記錄的操作都得排除等著B。

這樣子當然非常理想，由于不存在并發(fā)，自然也就消除了并發(fā)沖突的問題。但是，ADO處理這種鎖也存在著較為隱蔽的風險：如果A修改了數(shù)據(jù)，一直不提交，或者A因為故障，沒有辦法提交，那么，其它所有的相關(guān)的操作，都將被阻礙住。因此，只有對數(shù)據(jù)準確性要求極高并且用戶可以忍受等待的情況下，使用這種并發(fā)沖突的處理方法。