這是我的情況：我有Java EE單頁應用程序。所有客戶端 - 服務器通信都是基於AJAX的JSON格式來交換數據。我的一個請求需要大約1分鐘來計算客戶所需的數據。此外這個數據是巨大的（可能> 20 MB）。所以不可能一次將整個數據傳遞給JavaScript。所以出於這個原因，我只傳遞了幾個記錄到客戶端，並使用網格顯示數據與分頁選項。Java/Java EE應用程序的服務器端緩存
現在，當用戶點擊下一頁按鈕，我需要獲得更多的數據。我的問題是如何緩存服務器端的數據？我只需要爲一位用戶提供這些數據。你會建議使用會話ID作爲密鑰緩存所有數據第一個請求嗎？
其他建議？
Java EE Web應用程序中最便宜的（也並非如此無效的緩存數據）方式是使用Session對象，就像您打算這樣做。這是無效的，因爲它要求開發人員確保緩存不會泄漏內存;所以一旦對象不再需要時，開發人員就可以取消對該對象的引用。
但是，即使您希望實施窮人的緩存，緩存20MB數據也不可取，因爲它無法很好地擴展。當多個用戶使用應用程序的相同功能時，可擴展性問題就會增加，在這種情況下，20MB是大量數據。
根據ValueList design pattern，最好還是以JSON的形式返回分頁「數據集」。每個查詢數據的請求都會導致數據的部分檢索，然後將數據發送到客戶端。這樣，您永遠不必緩存查詢執行的完整結果，也可以返回部分數據集。至於是否要緩存，完全取決於您;通常緩存是針對一次又一次使用的大型數據集完成的。
我假設你正在使用DB後端。我會使用限制來返回小塊數據，大多數數據庫供應商都爲此提供瞭解決方案。這會讓你的查詢更快，而且大多數帶有網格類型組件的JS fameworks都會支持分頁結果（例如ExtJS）。
如果您從第三方獲取數據並將其傳遞（經過一些修改或不），我仍然堅持數據庫並使用這樣的工作流：來自第三方的池數據，保存在數據庫中，從您的小部件調用客戶要求的小塊。
希望這會有所幫助。
我別無選擇，只能在首次請求時一次性提取所有數據。同時填充這些數據也很昂貴，這就是爲什麼我不想每次都處理數據的原因。所以用DB查詢限制不是一個選項。謝謝。 – ashish 2010-08-02 12:05:12
只要用戶處於活動狀態（只要用戶會話有效），我需要將此數據保存在緩存中。性能是我熱衷於緩存這些大數據的唯一原因。請求部分數據與檢索所有數據集一樣昂貴。所以在每次請求時，大約需要1分鐘左右，這是不可接受的。無論如何，將繼續尋找更好的選擇。謝謝。 – ashish 2010-08-02 12:09:20