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

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

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

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

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

     摘要: 安全通信高級應用
中間證書：自簽證書-中間CA簽發(fā)證書-導入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
簽發(fā)人: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
簽發(fā)人:CN=mars_ca, OU=rv, O=rcd, L=ZB, ST=bj, C=China
別名名稱： icm
項類型: PrivateKeyEntry
認證鏈長度：  閱讀全文

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

     摘要: 服務器端業(yè)務接口繼承自Remote
服務器端業(yè)務實現(xiàn)該接口
服務器注冊遠程實現(xiàn)名稱
// style-1
Registry registry = LocateRegistry.createRegistry(RMIParameter.PORT);
registry.rebind(RMIParameter.NAME, bis); // replace existing binding name
// style-2
//java.rmi.Naming.rebind(RMIParameter.NAME, bis); // replace existing binding name
客戶端打樁調(diào)用Naming.lookup  閱讀全文

     摘要: 傳輸層安全訪問是通過身份驗證和加密傳輸?shù)倪^程。JDK的JSSE提供了傳輸層安全訪問的實現(xiàn)。本文旨在通過一個完整的TLS通訊實例，辨析一個普遍的誤導。  閱讀全文

     摘要: 線程池的特點是將任務的提交和執(zhí)行分開。這樣做的好處是，能使處理器盡量多地同時執(zhí)行任務。

1.當工人數(shù)量沒有達到最小雇傭數(shù)量時，每當任務來臨，線程池都要創(chuàng)建一個工人，把工人加入工人集合。

2.如果任務來臨時，當前工人數(shù)量poolSize已經(jīng)大于最小雇傭數(shù)量，線程池嘗試把任務加入任務列表，如果成功，任務提交的步驟就結束了。

2.5.工人會不斷地嘗試從隊列里獲取任務，如果獲取到任務(請看5)，工人就把任務拿去執(zhí)行。這是任務的執(zhí)行步驟。

3.如果加入隊列失敗，再雇傭一個工人或者
4.拒絕該任務。

5.工人等待任務的策略分兩種(本文不考慮生命周期和狀態(tài))：死等！在給定時間內(nèi)等。

6.沒有任務則把該工人的線程結束。

7.沒有拿到任務的工人，被清除出工人集合。  閱讀全文