摘要: 數據庫并發操作存在的異常情況：
1.更新丟失（LostUpdate）：
A和B事務并發執行，A事務執行更新后，提交；B事務在A事務更新后，B事務結束前也做了對該行數據的更新操作，然后回滾，則兩次更新操作都丟失了。

第一類丟失更新(回滾丟失，Lost update)。
在事務A期間，事務B對數據進行了更新；在事務A撤銷之后，覆蓋了事務B已經提交的數據。
SQL92沒有定義這種現象，標準定義的所有隔離界別都不允許第一類丟失更新發生。

第二類丟失更新(覆蓋丟失/兩次更新問題，Second lost update)。
在事務A期間，事務B對數據進行了更新；在事務A提交之后，覆蓋了事務B已經提交的數據。
第二類丟失更新，實際上和不可重復讀是同一種問題。

2.臟讀取（DirtyReads）：
A和B事務并發執行，B事務執行更新后，A事務查詢B事務沒有提交的數據，B事務回滾，則A事務得到的數據不是數據庫中的真實數據。也就是臟數據，即和數據庫中不一致的數據。

3.不可重復讀取  閱讀全文

     摘要: 安全通信高級應用
中間證書：自簽證書-中間CA簽發證書-導入KeyStore
keytool -list -v -keystore temp/iview.keystore -storepass 111111
您的 keystore 包含 3 輸入
別名名稱： root
輸入類型： trustedCertEntry
所有者:CN=mars_ca, OU=rv, O=rcd, L=ZB, ST=bj, C=China
簽發人:CN=mars_ca, OU=rv, O=rcd, L=ZB, ST=bj, C=China
別名名稱： intermediary
輸入類型： trustedCertEntry
所有者:CN=mars_inter, OU=rv, O=rcd, L=ZB, ST=bj, C=China
簽發人:CN=mars_ca, OU=rv, O=rcd, L=ZB, ST=bj, C=China
別名名稱： icm
項類型: PrivateKeyEntry
認證鏈長度：  閱讀全文

     摘要: 服務器端給第一個客戶端發送notification，然后在限定時間內，等待客戶端作出回應—向服務器發送request。如果客戶端一直沒有回復，服務器會在到達限定時間后，向第二個客戶端發送notification。如果客戶端在限定時間內回復，服務器端放棄再給其他客戶端發送消息。
Design
服務器、客戶端使用socket發送和接收信息
發送端存在一個客戶端列表，每次發送一給一個客戶端，發送后，向Helper發送添加該客戶端id的請求。
客戶端收到信息會向Helper發送刪除該id的請求。
Helper收到add時，啟動一個ScheduledExecutorService類的schedule，延時啟動一個線程，并將該schedule緩存。remove時，從緩存里取出schedule并停止它。如果在延時時間內，線程沒有被停止，它會被執行：從緩存中取出，告訴服務器向下一個客戶端發送請求。  閱讀全文