最近一直在想乙個關於事務處理層次的問題。平時我們在做j2ee應用的時候，習慣把應用分為三個邏輯層次，web層，業務層和持久層，比較經典的是持久層一般使用dao的設計方式。涉及到資料庫相關的事務處理時，很多人也就習慣於將事務處理**寫在dao這乙個層次上，也就是持久層這個層次。這樣寫對於簡單一點的資料庫訪問沒有什麼問題，一旦實現複雜一點，牽涉到的業務處理比較繁雜一點時，這種在dao裡面處理事務的方法就有點力不從心了。
打個比方，我乙個dbdao介面裡面有updatea和updateb兩個方法，這兩個方法中假設都會同時更新幾張表（這種情況很常見），這樣就會涉及到事務處理的問題，在updatea中，我們使用事務進行處理,在updateb中我們也謝了事務處理的語句。現在問題來了，如果乙個業務處理要求，如果updatea成功時，更新updateb，如果失敗，那麼都需要回滾，這樣的話，業務層呼叫了updatea成功提交之後，updateb卻失敗了，原來那個方法就沒有辦法回滾。當然，我們可以在dao中增加兩個沒有事務處理的方法來呼叫，但是請仔細想想，這樣合適麼？？？？？
不過，你也可以將部分業務實現寫到dao中去，這樣也可以處理，但是這樣業務層和持久層就明顯含混不清，失去了分層的意義。
因此我們想到把事務處理放到業務中去。原因很明顯，事務處理是業務處理的需要，理應隨業務的變化而變化，事務跟底層持久化毫不相干，也就是說dao層根本不應該出現事務處理的**。但是如果我們將資料庫事務處理**放到業務層之後，明顯感覺有點bad smell的味道。所以我們可以利用aop框架，例如，spring,將事務處理單獨提煉出來，對業務層進行事務控制。而dao層由於接收事務處理的任務，所以任何業務方法都可以放心呼叫，只有在需要事務的時候對業務方法新增事務即可。
PB事務處理
1 資料視窗更新，只要dberror有錯誤，而事先沒有做過任何commit工作，那麼rollback可以回滾到上次commit位置，即上次commit後所有的資料將被回滾。2 如果是直接寫入sql語句，只要資料庫出現錯誤，那麼rollback可以回滾到上次commit的位置，即上次commit後所有...
MySQL事務處理
start transaction,commit和rollback語法 start transaction begin work commit work and no chain no release rollback work and no chain no release set autocom...
ASP事務處理
asp事務處理。測試資料庫為sql server，伺服器為本機，資料庫名為test，表名為a，兩個欄位id int 主鍵標識,num int set conn server.createobject adodb.connection strconn provider sqloledb.1 persi...