1、如果僅僅考慮技術問題，那麼肯定會得出最壞的解答，因為技術是沒有智慧型的、最笨的東西，只有先用智慧型後用技術才能解決問題。
「查詢-訂票-收款-出票」是乙個事務不假，但是它並不是乙個1、2秒鐘的資料庫操作事務，而是乙個持續較長時間（例如超過10秒鐘）的業務。試想一下，如果乙個終端在處理一張車票的時候所有其它幾百的終端都被阻塞——「宕機」——在這裡了，或者幻讀、贓讀的終端每處理10次票僅能成功1次，而其它9次都會在操作員操作最後一步才出現提示「記錄已經被修改，您的操作被回滾放棄，請重新執行訂票流程」，這是多麼讓人懊惱的惡劣設計呀！
其實流程很簡單，就是在訂票開始就將票從「無人訂購」表移到乙個「正在處理」的表中。訂票點的操作，收款、出票等，都是針對「正在處理」表中具體的票資源的操作，並不去動別人正在處理的票。訂票點可以放棄處理從而把票放回「無人訂購」的表中，也有可能後台會在超時（例如2分鐘）之後自動處理這個。
事務鎖不是乙個業務處理的概念，而是乙個處理軟體編碼的後期細節的技術。如果大家都把高階的業務流程當成低階的計算機技術來看待，會給使用者帶來無盡的煩惱，會產生大量成事不足的「錯誤地技術化了」的解決方案。
提供的解決辦法還有一點問題，將「無人訂購」表移到「正在處理」的表時機如何掌握。如果是查詢時移動，到底要移走多少張票（我們買票時都是先只告知車次，售票點查詢之後再問我們要幾張票），如果全數移入「正在處理」的表，那此時別的地方查詢時就只能顯示車次的票售完；如果是先查詢，在出票時才移動，票可能已經被別的地方售出了，購買會失敗。
2、dbcommandbuilder中
public enum conflictoption
該列舉comparerowversion
如果表中存在任何 timestamp 列，則這些列在 where 子句中用於所有生成的更新語句。這等效於指定 comparerowversionupdate | comparerowversiondelete。
net2.0中使用dbdataadapter更新資料庫。套用dbcommandbuilder自動生成的sql語句，where部分卡的很嚴格的，基本欄位都要在where後面卡一下。如果有高精度的字段存在，可以防止併發。
3、事實上火車票的售票系統肯定是不會簡單的用事務來避免併發的。
可以為每乙個售票視窗預留一些車票，如10張，售一張就請求一張未售的票加入預留佇列，但未售的車票達到某個臨界值時，如20張，就開始按照各個售票視窗的出貨情況和缺貨情況來分配
資料庫併發處理方法
1 如果僅僅考慮技術問題，那麼肯定會得出最壞的解答，因為技術是沒有智慧型的 最笨的東西，只有先用智慧型後用技術才能解決問題。查詢 訂票 收款 出票 是乙個事務不假，但是它並不是乙個1 2秒鐘的資料庫操作事務，而是乙個持續較長時間 例如超過10秒鐘 的業務。試想一下，如果乙個終端在處理一張車票的時候所...
資料庫併發處理方法
1 如果僅僅考慮技術問題，那麼肯定會得出最壞的解答，因為技術是沒有智慧型的 最笨的東西，只有先用智慧型後用技術才能解決問題。查詢 訂票 收款 出票 是乙個事務不假，但是它並不是乙個1 2秒鐘的資料庫操作事務，而是乙個持續較長時間 例如超過10秒鐘 的業務。試想一下，如果乙個終端在處理一張車票的時候所...
php 資料庫併發處理
在並行系統中併發問題永遠不可忽視。儘管php語言原生沒有提供多執行緒機制，那並不意味著所有的操作都是執行緒安全的。尤其是在操作諸如訂單 支付等業務系統中，更需要注意運算元據庫的併發問題。接下來我通過乙個案例分析一下php運算元據庫時併發問題的處理問題。首先，我們有這樣一張資料表 mysql sele...