多使用者客戶端-伺服器應用程式中的併發性(資料處理的策略)
處理併發性問題的若干種方法：
1．保守方式：這種併發性模型在資料上加了鎖。如果乙個使用者已經開啟了一條記錄，那麼在允許編輯的環境中，系統就會拒絕來自其他使用者的讀取資料的請求。
2．開放方式：在開放的併發模型中，總是允許使用者讀取資料，甚至還可能允許更新資料。但是，當使用者試圖儲存資料時，系統會檢查自從這個使用者檢索資料以後是否有其他人更新過資料。如果資料發生了變化，那麼更新就失敗了。
3．沒有併發保護：「勝利屬於最後乙個使用者」。這是一種最簡單的模型，這種方法並不對多個使用者編輯相同的資料提供保護。如果兩個使用者開啟同一條記錄並且對它進行修改，那麼第二個使用者的修改結果會覆蓋第乙個使用者的修改結果，這就是一種「勝利屬於最後乙個使用者」的情形。
應用軟體處理併發性的方式會影響系統的效能、可使用性和資料完整性。因此，為了驗證應用程式在併發性處理方面是否正確，根據為專案選擇的併發性模型設計相應的併發性測試是非常重要的。
事務處理和併發性
1 全部的表型別都可以使用鎖，但是只有 innodb 和 bdb 才有內建的事務功能。2 使用 begin 開始事務，使用 commit 結束事務，中間可以使用 rollback 回滾事務。3 在預設情況下，innodb 表支援一致讀。sql 標準中定義了 4 個隔離級別 read uncommit...
併發中的原子性問題
高階語言的程式中，一條程式 可能對應多個cpu指令，而原子性，即指乙個或多個操作在cpu中執行的過程中不被中斷，稱為 原子性 而因為原子性出現的bug的原因是因為執行緒切換，即指乙個變數的讀取操作在cpu中可能存在多個執行緒同一時間執行不同的順序，導致值的不對。怎麼解決這個問題呢？原子性問題的根源，...
父子程序的併發性
參考 並行 是指無論從微觀還是巨集觀，二者都是一起執行的，就好像兩個人各拿一把 鐵杴在挖坑，一小時後，每人乙個大坑。併發 在微觀上不是同時執行的，只是把時間分成若干段，使多個程序快速交替的執行，從巨集觀外來看，好像是這些程序都在執行，這就好像兩個人用同一把鐵杴，輪流挖坑，一小時後，兩個人各挖乙個小一...