存個筆記，免得忘了。
由於專案需求原因，裡面經常用到回退快取資料的需求，用storage本地儲存的話，乙個處理疏忽就極容易觸發bug，於是我越來越鍾愛用input作為容器來儲存資料（僅對頁面回退讀取快取這一類需求使用，極度推薦，真的很好用）。
嗯，開始說正題，今天同樣在用input做回退快取需求時，突然報錯了，json.parse()方法報錯了，一開始我還很懵逼，然後除錯一下，發現我快取在input裡面的那個json資料變了，變的很徹底，嘗試了幾輪過後，發現賦值很正常，取值也正常，但是只要頁面回退，資料就變成頁面內其它input的內容了 ？？？然後我再嘗試了一下別的，很正常的執行，然後我就大膽的猜測一下，你input不支援我放太長的資料吧？於是我嘗試把資料縮短，縮短了幾次之後，果然又正常了，果然是這貨的鍋。但是知道了你的錯誤，卻不知道怎麼讓你放更長的資料啊。
於是我做了乙個英明的決定，把input 換成 textarea標籤，於是幸福就這麼突然的到來了，完美解決（手動滑稽）。
補充：
hibernate重新整理資料時的快取問題
眾所周知，hibernate是採取二級快取的策略，第一是session級別的快取，二是sessionfactory級別的快取，並且預設二級快取是開啟的。讀取資料的時候，hibernate將第一次讀取的內容放到了快取中，若此時有別的應用修改了資料庫中的資料，程式再次讀取的時候，內容是從快取中直接獲取，...
hibernate重新整理資料時的快取問題
今天碰見了乙個bug，兩個系統同使用乙個資料庫，兩個系統都採用的ssh框架，其中乙個系統更新了資料庫後，另乙個系統得5分鐘後才能取得更新的資料，腫麼回事呢？仔細查了查，原來是hibernate快取的問題，眾所周知，hibernate是採取二級快取的策略，第一是session級別的快取，二是sessi...
關於更新快取資料的方式
1.可以通過定時任務去定時更新快取資料 優點 開發簡單，實現起來比較方便。缺點 快取資料存在一定的精準性，不適合對要求精度比較高的資料使用如 實時的訂單資訊。2.根據業務邏輯更新快取，也就是在你對資料庫進行 增，刪，改時 同時更新快取，可以用spring aop 切面來實現。優點 快取的可信度比較高...