clr無法從com 上下文轉換為com上下文，這種狀態已持續60秒。
異常資訊：clr無法從com 上下文0x645e18 轉換為com上下文0x645f88，這種狀態已持續60秒。擁有目標上下文/單元的執行緒很有可能執行的是非幫浦式等待或者在不傳送 windows 訊息的情況下處理乙個執行時間非常長的操作.這種情況通常會影響到效能，甚至可能導致應用程式不響應或者使用的記憶體隨時間不斷累積。要避免此問題，所有單執行緒單元(sta)執行緒都應使用幫浦式等待基元(如 cowaitformultiplehandles)，並在執行時間很長的操作過程中定期傳送訊息。
如下圖所示
在debug -> exceptions -> managed debug assistants(中文版對應：除錯->視窗->異常設定）裡 去掉contextswitchdeadlock前面的鉤，如下圖所示。問題即可解決。
討論乙個併發執行緒導致的資料儲存失敗的問題
環境 前端採用非同步提交的方式，將選擇的多個附件分批傳送到服務端 後端採用標準的springmvc架構來處理請求，採用宣告式事務，控制在service層 現象 後台儲存附件資訊到資料庫的時候，總是報主鍵唯一性約束錯誤 分析 後台使用到了乙個uploadentity物件，該物件被配置成了乙個bean，...
乙個超時功能的設計
有乙個產品需求，需要執行某個動作之後，需要生成乙個超時的任務，在超時時間到了之後執行後續的動作，後續動作的執行大約耗時1秒鐘。任務允許在未到超時間刪除，超時時間不超過30天。要求在現有的產品架構上實現此功能。存在問題 方案二既然方案一存在持久化的問題，那麼只要解決這個問題即可，比如儲存在乙個公共的儲...
Calendar 導致的乙個bug
查詢不到資料。把calendar生成的date通過gettime 列印出時間戳。因為資料庫裡的資料是每天生成的，所以對應的時間毫秒為0，而calendar生成的時間沒有對毫秒進行set值覆蓋，導致使用到了當前時間的毫秒值。此時由於查詢條件是 導致這部分資料被忽略掉了。由於 calendar.geti...