(原)Java 專業人士必備的書籍和網站列表 您必備的參考資料

文檔選項 ? ? 未顯示需要 JavaScript 的文檔選項 拓展 Tomcat 應用 下載 IBM 開源 J2EE 應用服務器 WAS CE 新版本 V1.1

級別: 初級

Roy Miller (roy@roywmiller.com), 創始人兼總裁, The Other Road, LLC

2007 年 1 月 15 日

對于 Java? 語言開發人員來說，信息過量是一個真正的問題。每個新入行的程序員都要面臨一個令人畏縮的挑戰：要進入的行業是一個具有海量知識的行業。要了解的東西簡直太多了。對于有經驗的老手來說，情況只有些微好轉。知識量總在增大，僅僅跟上進度就是一個挑戰。如果有一份專業人士必備的書籍和網站列表該有多好！本文就是這個列表。它包含了每個專業的 Java 語言程序員在書架或瀏覽器書簽中必備的最重要的書籍和網站。

這些都是您書架上必備的書和應該經常使用的 Web 鏈接。時間是一項重要的資源，本文幫您回避那些分心的事情，把時間專注于最有益于您作為Java 語言程序員職業生涯的信息源。盡管有多少程序員就有多少他們最喜歡的參考資料，但本文收集的這些都是優中選優，來源于我書架上的私家珍藏和許多 Java 專家的推薦。

我考慮了兩種組織這份參考資料列表的方法。我本可以通過主題領域來組織，這也許很有幫助，但主題列表很快就會變得不實用。相反，我選擇了另一種方法：通過類型來組織，即書籍和 Web 站點。

總的來講，有經驗的老手們用 Web 站點來跟蹤行業的走勢。書籍、文章和論文有助于跟上潮流，但它們總體上更適合于基礎學習。極富創造性的書籍偶爾會撼動一兩個基礎性的東西。這樣的書也在本列表之列。

需要提出的一點警告是，專注于 Java 語言的書籍和 Web 站點數量巨大。您鐘愛的未必在這份列表里。那并不意味著它們不好。它們只是不在這份列表里而已。可能是因為我還不知道它們。也可能是因為我不認為它們能夠算得上是重要資源。不包含一些參考資料是一個評判問題，但如果不這樣的話，您也許就要花幾小時來拖動滾動條，還要花上成千上萬美元來買書。如果您作為一個專業的 Java 程序員，有一些常用的優秀參考資料，一定要讓我知道這些資料。這份列表一直都在更新中，您提出的那些也許就會被收錄進去。

書籍

每個程序員都會有一些由于經常被當作專業資料參閱而磨壞的書。下列書籍應該是 Java 語言程序員的書架上必備的。書很貴，所以我有意將這份列表弄得很短，僅限于重要書籍。

Thinking in Java (Bruce Eckel)

Thinking in Java, 3rd edition （Bruce Eckel; Prentice Hall PTR，2002 年）
Java 編程思想：第3版 （陳昊鵬 等譯; 機械工業出版社，2005 年）
Eckel 的書對于學習如何在 Java 語言環境中使用好面向對象技術極其實用。書中大量的代碼樣例解釋了他所介紹的概念。文字出自一個并不認為 Java 技術總是正確答案的人，所以相當地實用。Eckel 具有多種語言的大量經驗，還有用面向對象方式進行思考的扎實技能。本書將這些技能放到實用的 Java 語言環境中。他還在寫一本新書，名為 Thinking in Enterprise Java。

Effective Java (Joshua Bloch)

Effective Java: Programming Language Guide （Joshua Bloch; Addison-Wesley，2001 年）
Effective Java 中文版 （潘愛民 譯; 機械工業出版社，2003 年）
本書是理解優秀 Java 程序設計原則的最佳書籍。大多數材料從其他的 “學習 Java ” 的書中根本找不到。例如，Bloch 書中關于覆蓋 equals() 這一章是我讀過的最好的參考資料之一。他也在書中包括了很實用的建議：用接口替代抽象類和靈活使用異常。Bloch 是 Sun 公司 Java 平臺庫的架構師，所以他透徹地了解這門語言。事實上，他編寫了該語言中大量有用的庫。本書必讀！

The Java Programming Language (Ken Arnold, James Gosling, David Holmes)

The Java Programming Language （Ken Arnold，James Gosling，David Holmes; Addison-Wesley，2000 年）
Java 編程語言（第 3 版） （虞萬榮 等譯，中國電力出版社，2003 年）
這也許是能弄到的最好的 Java 入門讀物。它并不是一個標準規范，而是一本介紹每門語言特性的可讀書籍。這本書在嚴謹性和教育性方面權衡得很好，能夠讓懂編程的人迅速被 Java 語言（和其豐富的類庫）所吸引。

Concurrent Programming in Java: Design Principles and Patterns (Doug Lea)

Concurrent Programming in Java: Design Principles and Patterns, 2nd edition （Doug Lea; Addison-Wesley，1999 年）
Java 并發編程—設計原則與模式（第二版） （趙涌 等譯，中國電力出版社，2004 年）
不是每個開發人員都需要如此細致地了解并發性，也不是每個工程師都能達到本書的水準，但卻沒有比本書更好的關于并發性編程的概述了。如果您對此感興趣，請從這里開始。Lea 是 SUNY 的一名專業程序員，他的和并發性有關的作品和想法都包含在了 JDK 5.0 規范（引自 JSR166）中，所以您大可放心，他所說的關于有效使用 Java 語言的建議是值得一聽的。他是一個很善于溝通的人。

Expert One-On-One J2EE Design and Development (Rod Johnson)

Expert One-On-One J2EE Design and Development （Rod Johnson）
WROX: J2EE 設計開發編程指南 （魏海萍 譯，電子工業出版社，2003 年）
對于剛接觸 J2EE 的人來說，這是唯一的一本如實反映這項技術的書。本書收錄了多年的成功經驗和失敗經驗，不同于其他許多作者，Johnson 樂于將失敗的經驗公諸于眾。J2EE 常常都被過度使用。Johnson 的書能幫您避免這一點。

Refactoring (Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts)

Refactoring: Improving the Design of Existing Code （Martin Fowler，Kent Beck，John Brant，William Opdyke，Don Roberts; Addison-Wesley，1999 年）
重構：改善既有代碼的設計（中文版） （侯捷 等譯，中國電力出版社 ，2003 年）
Fowler 寫了幾本現已出版的最流行的編程書，包括 Analysis Patterns。他的關于重構 的書是這一主題的基本書籍。重構代碼是被程序員忽略的訓練，但卻是程序員最直觀的想法。重構是在不改變代碼結果的前提下改進現有代碼的設計。這是保持代碼整潔的最佳方式，用這種方法設計的代碼總是很容易修改。什么時候進行重構呢？當代碼“散發出味道”時。Fowler 的書里滿是 Java 語言代碼的例子。許多 Java 語言集成開發環境（IDE）（包括了 IBM 的 Eclipse）都將 Fowler 的重構包含了進去，每一個都使用他的重構名命名，所以熟悉如extract method 等重構方法還是很值得的。

Design Patterns (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides)

Design Patterns: Elements of Reusable Object Oriented Software （Erich Gamma，Richard Helm，Ralph Johnson，John Vlissides; Addison-Wesley，1997 年）
設計模式：可復用面向對象軟件的基礎 （李英軍 等譯，機械工業出版社 ，2005 年）
這是一本在專業程序員圈子里更為有名的書，基于作者共同的綽號，這本書被認為是 “四人幫（GOF）之書”。模式是思考和解決普通編程問題時可以重用的方式。學習模式是一門學科。使用好模式（或知道什么時候不 使用模式）是一項技能。忽略模式則是錯誤的。書中所有的例子都以 C++ 表示，但 Java 語言是從那里誕生的，讓 Java 語言程序員由此聯系到如何在 Java 語言中實現這些模式相對簡單一些。熟悉模式并了解如何使用好模式使編程更加簡單。這使得和其他程序員交流也更簡單，因為在針對通用問題的通用解決方案中，模式是描述解決方案中彼此協作的大量相關編程概念的快捷方式。一些更為通用的方式，如工廠方法 則是普便存在的，甚至存在于 Java 語言本身。關于明智使用模式的這個主題，也可以閱讀 Joshua Kerievsky 的 Refactoring to Patterns，該書稱可以讓代碼來告訴您何時實現模式。

Patterns of Enterprise Application Architecture (Martin Fowler)

Patterns of Enterprise Application Architecture （Martin Fowler; Addison-Wesley，2002 年）
企業應用架構模式 （王懷民 等譯，機械工業出版社 ，2004 年）
比起小型、一次性項目來說，企業開發當然代表了更大的挑戰。那并不意味著企業開發帶來的所有挑戰都是新挑戰。事實上有些時候，這項開發已經 是以前完成過的了。Fowler 做了很多個這樣的項目。他的書提到了一些通用解決方案，并提供了關于使用、折中和可選方案的指導。Fowler 在書中包含了一些熟悉的模式，如模型視圖控制器（MVC），他也提供了一些您也許不了解的模式，如處理 Web 站點上特定頁面請求或行為請求的 Page Controller 模式。正如您對待大多數模式一樣，一旦您讀過許多模式，您就會認為 “我已經知道那個模式了” 。也許是這樣，但有一個用來引用模式的通用表達方式還是很有幫助的。在有多個組件（由不同人開發）的大型項目中，該類引用是一項很好的幫助。

UML Distilled (Martin Fowler)

UML Distilled: A Brief Guide to the Standard Object Modeling Language （Martin Fowler; Addison-Wesley 2003 年）
UML精粹：標準對象語言簡明指南（第3版） （徐家福 譯，清華大學出版社 ，2005 年）
對于專業的程序員來說，UML 是一門很重要的通用可視化溝通語言，但是它被過度使用和草率地濫用了。您無需對使用 UML 溝通了解太多。Martin 對 UML 的提煉為您提供了最核心的東西。事實上，前后的封頁提供了常規基礎上可能使用到的所有東西。該書中 UML 例子的代碼都是 Java 代碼。

Test-Driven Development: By Example (Kent Beck)

Test-Driven Development: By Example （Kent Beck; Addison-Wesley 2002 年）
測試驅動開發（中文版） （崔凱 譯，中國電力出版社 ，2004 年）
測試優先編程將使編程發生革命性變化，能助您成為更好的程序員。在寫代碼之前編寫測試開始很難，但卻是一項威力強大的技能。通過優先編寫測試，可使代碼更加簡單，并確保從一開始它就能工作（Beck 實踐著他提倡的測試優先，與人合寫了 JUnit，這是 Java 語言最流行的測試框架）。Beck 的書是權威的參考資料，擴展了的 Money 例子也用 Java 語言寫成。Beck 詳述了如何用測試優先進行 思考（這也許是許多程序員首先遇到的障礙）。

The Pragmatic Programmer: From Journeyman to Master (Andy Hunt and Dave Thomas)

The Pragmatic Programmer: From Journeyman to Master （Andrew Hunt 和 David Thomas; Addison-Wesley 1999 年）
程序員修煉之道——從小工到專家 （馬維達 譯，電子工業出版社 ，2004 年）
做一個純粹的面向對象開發人員有其優勢所在。在當今復雜的社會中，作為 Java 語言開發人員，為完成任務常要妥協。Hunt 和 Thomas 探討了如何不將真正重要的東西妥協掉而完成任務。這不是一本關于 Java 語言的書，而是 Java 語言開發人員重要的思想讀物。例如，我認為沒從“要解決問題，而不是推卸責任”這句忠言中受益的程序員，不能像個自豪的藝術家一樣在他的杰作上簽上大名。

Peopleware: Productive Projects and Teams (Tom DeMarco and Timothy Lister)

Peopleware: Productive Projects and Teams （Tom DeMarco，Timothy Lister; Dorset House，1999 年）
人件（第2版） （UMLChina 翻譯組 譯，清華大學出版社 ，2003 年）
這份列表中的其他所有書籍都至少和技術有些相關。這本書卻不是。在所有技術行話和首字母縮略詞的海洋中，有時軟件開發人員和經理們會忘記：是人 制造了軟件。DeMarco 和 Lister 向我們提醒了這一事實，也向我們提醒了形成這一區別的原因。這不是一本關于一門特定編程語言的書籍，但卻是每個 Java 語言程序員都應該讀的書。關于 “累死程序員如何讓經理們適得其反” 還有許多其他的好書，但這是最好的一本。

回頁首

Web 站點

Web 站點的數目浩如煙海，如果您想要消化其中的內容，窮畢生之力也難以全部訪問。包含 Java 語言某方面內容的詳盡的網站列表會大得離譜。下列站點都是可靠、真實的。

Sun 的 Java 技術站點

Sun 的 Java 語言站點
這是 Sun 的 Java 語言主站。作為 Java 語言開發人員，您會發現自己頻繁地訪問此站點。下列鏈接特別重要，特別是對新入行的 Java 語言開發人員：

• New to Java Center
  New to Java Center
  New to Java Center 存放了許多循序漸進的 Java 技術資源鏈接。如果您剛接觸這門語言，這是一個好的起點。
• 教程和代碼庫
  Java Tutorial
  這里有大名鼎鼎的 Java Tutorial，以及關于 Java 語言各個方面（例如 Collection）的其他教程。

IBM developerWorks

IBM 的 developerWorks
推銷自己也許有些厚臉皮，但 developerWorks 是一項巨大的資源，收錄了大量 Java 語言工具和技術的教程和文章。其內容從初學者指南到學習這門語言到高級并發性技術。可以根據主題搜索內容，然后根據類型瀏覽。

Apache Software Foundation

Apache Software Foundation
Apache 站點是許多可重用庫（通用領域）和工具的主頁，這些庫和工具幫助 Java 開發人員進行開發。這里的內容全都是開放源碼，所以盡管下載想要的吧！許多極其流行的 Java 語言庫和工具（如 Struts、Ant 和 Tomcat）都始于 Apache 項目。Jakarta 專區匯聚了大多數新興的 Java 語言材料。

Eclipse.org

Eclipse
有幾個好的 Java 語言集成開發環境（IDE）。Eclipse（來自 IBM）是最新的 IDE 之一，它很快成為 Java 語言開發的首要 IDE。它完全是開源的，這意味著它是免費的。該站包含了學習如何有效使用 Eclipse 的各種參考資料。這里還有關于 Standard Widget Toolkit（SWT）的信息，SWT 是相對于 Swing 來說更加輕量級的選擇。

Eclipse 插件中心和 Eclipse 插件

Eclipse 插件中心 和 Eclipse 插件
Eclipse 基于插件架構。事實上，插件是 Eclipse 的 Java 語言開發組件。但有差不多上千個插件，從 Web 開發的插件到在 Eclipse 環境中玩游戲的插件。這兩個站點分類列出了大多數插件，可以進行搜索。它們是很棒的資源。如果您想在 Eclipse 開發環境中弄點新東西，幸運的話有某個插件可能已經實現，從這兩個站點能找到想要的插件。這兩個站點都允許評論插件，這樣您就可以知道哪些插件好，哪些值得一試。

JUnit.org

JUnit.org
Junit 是 Java 語言中一個基本的單元測試框架。該站點包含了 Junit 最新最棒的版本，外加大量有關測試（Java 語言或者其他語言的）各個層面上（針對桌面應用程序、Web 應用程序、J2EE 應用程序等）的其他資源。如果您想找測試資源，這里就是最佳起點。

TheServerSide.com

TheServerSide.com
如果您要(或將要)從事服務器端 Java 語言的開發，此站點是一處舉足輕重的資源。您可以到這里找到有關 JBoss、J2EE、LDAP、Struts 和大量其他主題的文章，并且都是完全可檢索的。這些文章不僅僅是簡單描述 Java 語言的特征或者支持的庫。它們更進一步地描述了庫的新奇用法（如使用 Jakarta Velocity 作為規則引擎，而不是模板引擎）。它們也提供了有關 Java 語言現狀的連續評論（當前的一篇文章是由 Tim Bray 所寫的 Java is boring ）。該站點更好的通用功能之一是對 Java 語言工具和產品（應用服務器等）的矩陣式比較。

Bruce Eckel's MindView, Inc.

Bruce Eckel's MindView, Inc.
Eckel 寫了幾本 “用 …… 進行思考” 的書，內容關于 Java 語言、Python 和 C++ ，當我學習 Java 語言時，他的 Thinking in Java 對我尤其有幫助。它很實用并切中要害，在“在 Java 語言環境中如何面向對象思考”方面具有卓識。您可以從此站點免費下載他所有書籍的電子版。他也寫了許多好文章，并且他把這些文章的鏈接都放到了這里（包括關于 Jython、Java 和 .NET 比較等內容的文章）。

ONJava.com

ONJava.com
O'Reilley 歷年來出版了一些有關編程語言和工具的優秀書籍。他們的專注于 Java 語言的網站也不錯。它有些有關各種 Java 語言工具（如 JDOM 和 Hibernate）、Java 平臺（如 J2SE 和 J2EE）不同領域不同部分的文章。全部都可以被檢索到。他們有優秀的文章和教程。該站點按主題排列。例如有 Java 和 XML、Java Security、Wireless Java 和 Java SysAdmin。該站點也有到 O'Reilley Learning Lab 的鏈接，在那里您能獲得在線參考資料（Java 語言相關和其他的）。那些不是免費的，但是許多都面向大學認證。因此您可以以一種很方便的方式來學習技能，并得到一些認證。

java.net

java.net 社區
java.net 社區有多個“社區”，有特定于主題的論壇和文章。例如 Java Desktop 社區有各類與 Java 語言桌面開發相關的資料。Java Patterns 社區作為一個門戶，也許對提供 Java 語言的模式資源相當感興趣。還有一個 Java User Groups (JUG) 社區，在那里能找到有關創建、加入和管理一個 JUG 的信息。

回頁首

結束語

任何 “好的”、“關鍵性的” 或者 “重要的” 參考資料列表都注定是不完整的，本文的列表也未能例外。 Java 語言的書籍數目眾多，當然，萬維網也很龐大。除本文所列的參考資料之外，還有很多用于學習 Java 語言的參考資料。但如果您擁有了這里所提到的所有書籍、網站、文章或者教程，您應當已經擁有了一個使您良好開端并助您登堂入室的實用寶庫。

最后，要成為一個能力日增和高效的 Java 語言開發人員，方法就是用它工作，動手來嘗試。如果有一個教程詳細介紹了所需創建的軟件的每一部分，您很可能并沒得到多少好處。有時，您可能得走自己的路。在成功地嘗試了一些新的東西之后，您可能想要寫一篇文章、教程或者一本書來分享您所學到的。

參考資料

• 您可以參閱本文在 developerWorks 全球站點上的 英文原文 。
  
  
• 在 developerWorks Java 技術專區 查找更多 Java 技術參考資料。
  
  
• 訪問 Java 技術新手入門 站點，獲取最新的參考資料，幫您開始使用 Java 編程。
  
  
• 通過參與 developerWorks blog 加入 developerWorks 社區。
  
  
• 瀏覽 關于這些主題和其他技術主題的書籍。
  

關于作者

		Roy Miller 是一名獨立軟件開發培訓師、程序員兼作家，他在充滿挑戰、快節奏的咨詢公司里從事了十多年軟件開發和項目管理工作。他最初在 Andersen Consulting（現在是 Accenture）公司工作，在那里，他管理團隊實現了許多系統，從主機記帳系統到星形模式數據集市。最近三年來，他在北卡羅來納州 Holly Springs 的 RoleModel Software, Inc. 公司工作，在那里他專業地運用著 Java 技術，并擔任開發人員兼 Extreme Programming (XP) 培訓師。他與人合著了 Addison-Wesley XP 系列的 Extreme Programming Applied: Playing to Win 一書，最近他寫了 Managing Software for Growth: Without Fear, Control and the Manufacturing Mindset 一書，來幫助經理和管理層理解：像 XP 這樣的敏捷構建方法為什么比傳統的方法更有效。2003 年，他創辦了自己的公司：The Other Road，該公司幫助其他公司了解如何向 XP 和被他稱為 Extreme Business (XB) 的方法轉換。

如何在JSP頁面中訪問web.xml中的初始化參數?

<context-param>
 <param-name>productId</param-name>
如何從java代碼中訪問web.xml 中的初始化參數? 
你可以使用externalContext的 getInitParameter 方法得到他們.例如 如果你的參數如下: 
<context-param>
 <param-name>connectionString</param-name>
 <param-value>jdbc:oracle:thin:scott/tiger@cartman:1521:O901DB</param-value>
</context-param>
你可以使用下面代碼訪問connectionString : 
FacesContext?fc?=?FacesContext.getCurrentInstance();
String?connection?=?fc.getExternalContext().getInitParameter("connectionString");
?

使用backing bean來添加UIComponents 到頁面中?

<%@taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<%@taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
<%@taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%>
<html>
<f:view>
<head>
<title>jsp1</title>
  <link rel="stylesheet" type="text/css" href="./style.css" title="Style"/>
</head>
<body bgcolor="#ffffff">  TESTING...
  <h:form id="form1">
    <h:panelGrid id="panelgridtest" binding="#{jsp1Bean.component}"/>
  </h:form>
</body>
</f:view>
</html>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"
                              "http://java.sun.com/dtd/web-facesconfig_1_1.dtd">
<faces-config>
  <navigation-rule>
    <from-view-id>/jsp1</from-view-id>
    <navigation-case>
      <from-action>submit</from-action>
      <to-view-id>/jsp1</to-view-id>
      <redirect/>
    </navigation-case>
  </navigation-rule>
  <managed-bean>
    <managed-bean-name>jsp1Bean</managed-bean-name>
    <managed-bean-class>test.Jsp1Bean</managed-bean-class>
    <managed-bean-scope>session</managed-bean-scope>
  </managed-bean>
</faces-config>

如何在BackBean中使用SelectMany 對象?

 <managed-bean>
  <managed-bean-name>Manager</managed-bean-name>
 <managed-bean-class>demo.Manager</managed-bean-class>
  <managed-bean-scope>request</managed-bean-scope>
 <managed-bean>

<h:selectManyMenu binding="#{Manager.list}">

How to foward to another JSP from an actionListener ActionEvent

如何為每一個錯誤消息顯示一個圖片

<div align="center">
 <h:messages id="errMsgs" styleClass="errorFeedback" layout="table" />
</div>

??errorFeedback style class 可能是下面的代碼:

.errorFeedback {
 color: black;
 vertical-align: middle;
 background-image: url(/AccountSetup/images/warning_feedback.gif);
 background-repeat: no-repeat;
 background-position: left top;
 font-family: Verdana, Arial, Helvetica, sans-serif;
 font-weight: bold;
 line-height: 18px;
 font-size: 10pt;
 text-align: left;
 text-indent: 22px;}

(轉) 從 Filter和Servlet中如何訪問FacesContext?

?

J2EE 全面簡介(轉載)

本文從五個方面對J2EE進行了比較全面的介紹。從J2EE的概念說起，到它的優勢，到J2EE典型的四層模型，和它的框架結構，最后是J2EE十三種核心技術的一個簡介。本文分門別類的對J2EE中的服務，組件，層次，容器，API都做了比較詳細的介紹，相信看完此文，讀者會對J2EE有一個更清晰的認識。

J2EE的概念

目前，Java 2平臺有3個版本，它們是適用于小型設備和智能卡的Java 2平臺Micro版（Java 2 Platform Micro Edition，J2ME）、適用于桌面系統的Java 2平臺標準版（Java 2 Platform Standard Edition，J2SE）、適用于創建服務器應用程序和服務的Java 2平臺企業版（Java 2 Platform Enterprise Edition，J2EE）。

J2EE是一種利用Java 2平臺來簡化企業解決方案的開發、部署和管理相關的復雜問題的體系結構。J2EE技術的基礎就是核心Java平臺或Java 2平臺的標準版，J2EE不僅鞏固了標準版中的許多優點，例如"編寫一次、隨處運行"的特性、方便存取數據庫的JDBC API、CORBA技術以及能夠在Internet應用中保護數據的安全模式等等，同時還提供了對 EJB（Enterprise JavaBeans）、Java Servlets API、JSP（Java Server Pages）以及XML技術的全面支持。其最終目的就是成為一個能夠使企業開發者大幅縮短投放市場時間的體系結構。

J2EE體系結構提供中間層集成框架用來滿足無需太多費用而又需要高可用性、高可靠性以及可擴展性的應用的需求。通過提供統一的開發平臺，J2EE降低了開發多層應用的費用和復雜性，同時提供對現有應用程序集成強有力支持，完全支持Enterprise JavaBeans，有良好的向導支持打包和部署應用，添加目錄支持，增強了安全機制，提高了性能。

回頁首

J2EE的優勢

J2EE為搭建具有可伸縮性、靈活性、易維護性的商務系統提供了良好的機制:

1. 保留現存的IT資產: 由于企業必須適應新的商業需求，利用已有的企業信息系統方面的投資，而不是重新制定全盤方案就變得很重要。這樣，一個以漸進的（而不是激進的，全盤否定的）方式建立在已有系統之上的服務器端平臺機制是公司所需求的。J2EE架構可以充分利用用戶原有的投資，如一些公司使用的BEA Tuxedo、IBM CICS, IBM Encina,、Inprise VisiBroker 以及Netscape Application Server。這之所以成為可能是因為J2EE擁有廣泛的業界支持和一些重要的'企業計算'領域供應商的參與。每一個供應商都對現有的客戶提供了不用廢棄已有投資，進入可移植的J2EE領域的升級途徑。由于基于J2EE平臺的產品幾乎能夠在任何操作系統和硬件配置上運行，現有的操作系統和硬件也能被保留使用。
2. 高效的開發: J2EE允許公司把一些通用的、很繁瑣的服務端任務交給中間件供應商去完成。這樣開發人員可以集中精力在如何創建商業邏輯上，相應地縮短了開發時間。高級中間件供應商提供以下這些復雜的中間件服務:
   • 狀態管理服務 -- 讓開發人員寫更少的代碼，不用關心如何管理狀態，這樣能夠更快地完成程序開發。
   • 持續性服務 -- 讓開發人員不用對數據訪問邏輯進行編碼就能編寫應用程序，能生成更輕巧，與數據庫無關的應用程序，這種應用程序更易于開發與維護。
   • 分布式共享數據對象CACHE服務 -- 讓開發人員編制高性能的系統，極大提高整體部署的伸縮性。
3. 支持異構環境: J2EE能夠開發部署在異構環境中的可移植程序。基于J2EE的應用程序不依賴任何特定操作系統、中間件、硬件。因此設計合理的基于J2EE的程序只需開發一次就可部署到各種平臺。這在典型的異構企業計算環境中是十分關鍵的。J2EE標準也允許客戶訂購與J2EE兼容的第三方的現成的組件，把他們部署到異構環境中，節省了由自己制訂整個方案所需的費用。
4. 可伸縮性: 企業必須要選擇一種服務器端平臺，這種平臺應能提供極佳的可伸縮性去滿足那些在他們系統上進行商業運作的大批新客戶。基于J2EE平臺的應用程序可被部署到各種操作系統上。例如可被部署到高端UNIX與大型機系統，這種系統單機可支持64至256個處理器。（這是NT服務器所望塵莫及的）J2EE領域的供應商提供了更為廣泛的負載平衡策略。能消除系統中的瓶頸，允許多臺服務器集成部署。這種部署可達數千個處理器，實現可高度伸縮的系統，滿足未來商業應用的需要。
5. 穩定的可用性: 一個服務器端平臺必須能全天候運轉以滿足公司客戶、合作伙伴的需要。因為INTERNET是全球化的、無處不在的，即使在夜間按計劃停機也可能造成嚴重損失。若是意外停機，那會有災難性后果。J2EE部署到可靠的操作環境中，他們支持長期的可用性。一些J2EE部署在WINDOWS環境中，客戶也可選擇健壯性能更好的操作系統如Sun Solaris、IBM OS/390。最健壯的操作系統可達到99.999%的可用性或每年只需5分鐘停機時間。這是實時性很強商業系統理想的選擇。

回頁首

J2EE 的四層模型

J2EE使用多層的分布式應用模型，應用邏輯按功能劃分為組件，各個應用組件根據他們所在的層分布在不同的機器上。事實上，sun設計J2EE的初衷正是為了解決兩層模式(client/server)的弊端，在傳統模式中，客戶端擔當了過多的角色而顯得臃腫，在這種模式中，第一次部署的時候比較容易，但難于升級或改進，可伸展性也不理想，而且經常基于某種專有的協議?D?D通常是某種數據庫協議。它使得重用業務邏輯和界面邏輯非常困難。現在J2EE 的多層企業級應用模型將兩層化模型中的不同層面切分成許多層。一個多層化應用能夠為不同的每種服務提供一個獨立的層，以下是 J2EE 典型的四層結構:

• 運行在客戶端機器上的客戶層組件
• 運行在J2EE服務器上的Web層組件
• 運行在J2EE服務器上的業務邏輯層組件
• 運行在EIS服務器上的企業信息系統(Enterprise information system)層軟件

J2EE應用程序組件
J2EE應用程序是由組件構成的.J2EE組件是具有獨立功能的軟件單元，它們通過相關的類和文件組裝成J2EE應用程序，并與其他組件交互。J2EE說明書中定義了以下的J2EE組件:

• 應用客戶端程序和applets是客戶層組件.
• Java Servlet和JavaServer Pages(JSP)是web層組件.
• Enterprise JavaBeans(EJB)是業務層組件.

客戶層組件
J2EE應用程序可以是基于web方式的,也可以是基于傳統方式的.

web 層組件
J2EE web層組件可以是JSP 頁面或Servlets.按照J2EE規范，靜態的HTML頁面和Applets不算是web層組件。

正如下圖所示的客戶層那樣，web層可能包含某些 JavaBean 對象來處理用戶輸入，并把輸入發送給運行在業務層上的enterprise bean 來進行處理。

業務層組件
業務層代碼的邏輯用來滿足銀行，零售，金融等特殊商務領域的需要,由運行在業務層上的enterprise bean 進行處理. 下圖表明了一個enterprise bean 是如何從客戶端程序接收數據，進行處理(如果必要的話), 并發送到EIS 層儲存的，這個過程也可以逆向進行。

有三種企業級的bean: 會話(session) beans, 實體(entity) beans, 和消息驅動(message-driven) beans. 會話bean 表示與客戶端程序的臨時交互. 當客戶端程序執行完后, 會話bean 和相關數據就會消失. 相反, 實體bean 表示數據庫的表中一行永久的記錄. 當客戶端程序中止或服務器關閉時, 就會有潛在的服務保證實體bean 的數據得以保存.消息驅動 bean 結合了會話bean 和 JMS的消息監聽器的特性, 允許一個業務層組件異步接收JMS 消息.

企業信息系統層
企業信息系統層處理企業信息系統軟件包括企業基礎建設系統例如企業資源計劃 (ERP), 大型機事務處理, 數據庫系統,和其它的遺留信息系統. 例如，J2EE 應用組件可能為了數據庫連接需要訪問企業信息系統

回頁首

J2EE 的結構

這種基于組件，具有平臺無關性的J2EE 結構使得J2EE 程序的編寫十分簡單，因為業務邏輯被封裝成可復用的組件，并且J2EE 服務器以容器的形式為所有的組件類型提供后臺服務. 因為你不用自己開發這種服務, 所以你可以集中精力解決手頭的業務問題.

容器和服務
容器設置定制了J2EE服務器所提供得內在支持，包括安全，事務管理，JNDI(Java Naming and Directory Interface)尋址,遠程連接等服務，以下列出最重要的幾種服務：

• J2EE安全(Security)模型可以讓你配置 web 組件或enterprise bean ,這樣只有被授權的用戶才能訪問系統資源. 每一客戶屬于一個特別的角色，而每個角色只允許激活特定的方法。你應在enterprise bean的布置描述中聲明角色和可被激活的方法。由于這種聲明性的方法，你不必編寫加強安全性的規則。
• J2EE 事務管理（Transaction Management）模型讓你指定組成一個事務中所有方法間的關系，這樣一個事務中的所有方法被當成一個單一的單元. 當客戶端激活一個enterprise bean中的方法，容器介入一管理事務。因有容器管理事務，在enterprise bean中不必對事務的邊界進行編碼。要求控制分布式事務的代碼會非常復雜。你只需在布置描述文件中聲明enterprise bean的事務屬性，而不用編寫并調試復雜的代碼。容器將讀此文件并為你處理此enterprise bean的事務。
• JNDI 尋址(JNDI Lookup)服務向企業內的多重名字和目錄服務提供了一個統一的接口,這樣應用程序組件可以訪問名字和目錄服務.
• J2EE遠程連接（Remote Client Connectivity）模型管理客戶端和enterprise bean間的低層交互. 當一個enterprise bean創建后, 一個客戶端可以調用它的方法就象它和客戶端位于同一虛擬機上一樣.
• 生存周期管理（Life Cycle Management）模型管理enterprise bean的創建和移除,一個enterprise bean在其生存周期中將會歷經幾種狀態。容器創建enterprise bean，并在可用實例池與活動狀態中移動他，而最終將其從容器中移除。即使可以調用enterprise bean的create及remove方法，容器也將會在后臺執行這些任務。
• 數據庫連接池（Database Connection Pooling）模型是一個有價值的資源。獲取數據庫連接是一項耗時的工作，而且連接數非常有限。容器通過管理連接池來緩和這些問題。enterprise bean可從池中迅速獲取連接。在bean釋放連接之可為其他bean使用。

容器類型
J2EE應用組件可以安裝部署到以下幾種容器中去:

• EJB 容器管理所有J2EE 應用程序中企業級bean 的執行. enterprise bean 和它們的容器運行在J2EE 服務器上.
• Web 容器管理所有J2EE 應用程序中JSP頁面和Servlet組件的執行. Web 組件和它們的容器運行在J2EE 服務器上.
• 應用程序客戶端容器管理所有J2EE應用程序中應用程序客戶端組件的執行. 應用程序客戶端和它們的容器運行在J2EE 服務器上.
• Applet 容器是運行在客戶端機器上的web瀏覽器和 Java 插件的結合.

回頁首

J2EE的核心API與組件

J2EE平臺由一整套服務（Services）、應用程序接口（APIs）和協議構成，它對開發基于Web的多層應用提供了功能支持，下面對J2EE中的13種技術規范進行簡單的描述(限于篇幅，這里只能進行簡單的描述):

1. JDBC(Java Database Connectivity): JDBC API為訪問不同的數據庫提供了一種統一的途徑，象ODBC一樣，JDBC對開發者屏蔽了一些細節問題，另外，JDCB對數據庫的訪問也具有平臺無關性。
2. JNDI(Java Name and Directory Interface): JNDI API被用于執行名字和目錄服務。它提供了一致的模型來存取和操作企業級的資源如DNS和LDAP，本地文件系統，或應用服務器中的對象。
3. EJB(Enterprise JavaBean): J2EE技術之所以贏得某體廣泛重視的原因之一就是EJB。它們提供了一個框架來開發和實施分布式商務邏輯，由此很顯著地簡化了具有可伸縮性和高度復雜的企業級應用的開發。EJB規范定義了EJB組件在何時如何與它們的容器進行交互作用。容器負責提供公用的服務，例如目錄服務、事務管理、安全性、資源緩沖池以及容錯性。但這里值得注意的是，EJB并不是實現J2EE的唯一途徑。正是由于J2EE的開放性，使得有的廠商能夠以一種和EJB平行的方式來達到同樣的目的。
4. RMI(Remote Method Invoke): 正如其名字所表示的那樣，RMI協議調用遠程對象上方法。它使用了序列化方式在客戶端和服務器端傳遞數據。RMI是一種被EJB使用的更底層的協議。
5. Java IDL/CORBA: 在Java IDL的支持下，開發人員可以將Java和CORBA集成在一起。他們可以創建Java對象并使之可在CORBA ORB中展開, 或者他們還可以創建Java類并作為和其它ORB一起展開的CORBA對象的客戶。后一種方法提供了另外一種途徑，通過它Java可以被用于將你的新的應用和舊的系統相集成。
6. JSP(Java Server Pages): JSP頁面由HTML代碼和嵌入其中的Java代碼所組成。服務器在頁面被客戶端所請求以后對這些Java代碼進行處理，然后將生成的HTML頁面返回給客戶端的瀏覽器。
7. Java Servlet: Servlet是一種小型的Java程序，它擴展了Web服務器的功能。作為一種服務器端的應用，當被請求時開始執行，這和CGI Perl腳本很相似。Servlet提供的功能大多與JSP類似，不過實現的方式不同。JSP通常是大多數HTML代碼中嵌入少量的Java代碼，而servlets全部由Java寫成并且生成HTML。
8. XML(Extensible Markup Language): XML是一種可以用來定義其它標記語言的語言。它被用來在不同的商務過程中共享數據。XML的發展和Java是相互獨立的，但是，它和Java具有的相同目標正是平臺獨立性。通過將Java和XML的組合，您可以得到一個完美的具有平臺獨立性的解決方案。
9. JMS(Java Message Service): MS是用于和面向消息的中間件相互通信的應用程序接口(API)。它既支持點對點的域，有支持發布/訂閱(publish/subscribe)類型的域，并且提供對下列類型的支持：經認可的消息傳遞,事務型消息的傳遞，一致性消息和具有持久性的訂閱者支持。JMS還提供了另一種方式來對您的應用與舊的后臺系統相集成。
10. JTA(Java Transaction Architecture): JTA定義了一種標準的API，應用系統由此可以訪問各種事務監控。
11. JTS(Java Transaction Service): JTS是CORBA OTS事務監控的基本的實現。JTS規定了事務管理器的實現方式。該事務管理器是在高層支持Java Transaction API (JTA)規范，并且在較底層實現OMG OTS specification的Java映像。JTS事務管理器為應用服務器、資源管理器、獨立的應用以及通信資源管理器提供了事務服務。
12. JavaMail: JavaMail是用于存取郵件服務器的API，它提供了一套郵件服務器的抽象類。不僅支持SMTP服務器，也支持IMAP服務器。
13. JTA(JavaBeans Activation Framework): JavaMail利用JAF來處理MIME編碼的郵件附件。MIME的字節流可以被轉換成Java對象，或者轉換自Java對象。大多數應用都可以不需要直接使用JAF。

from:http://www.javaeye.com/topic/9706

數據庫對象的緩存策略

前言
本文探討Jive(曾經開源的Java論壇)和Hibernate（Java開源持久層）的數據庫對象的緩存策略，并闡述作者本人的Lightor（Java開源持久層）采用的數據庫對象緩存策略。
本文的探討基于以前開源的Jive代碼，Hibernate2.1.7源碼，和作者本人的Lightor代碼。
本文用ID (Identifier的縮寫)來代表數據記錄的關鍵字。
數據對象查詢一般分為兩種：條件查詢，返回一個滿足條件的數據對象列表； ID查詢，返回ID對應的數據對象。
本文主要探討“條件查詢”和“ID查詢”這兩種情況的緩存策略。
本文只探討一個JVM內的數據緩存策略，不涉及分布式緩存；本文只探討對應單表的數據對象的緩存，不涉及關聯表對象的情況。

一、Jive的緩存策略
1．Jive的緩存策略的過程描述：
(1)條件查詢的時候，Jive用 select id from table_name where …. （只選擇ID字段）這樣的SQL語句查詢數據庫，來獲得一個ID列表。
(2) Jive根據ID列表中的每個ID，首先查看緩存中是否存在對應ID的數據對象：如果存在，那么直接取出，加入到 結果列表中；如果不存在，那么通過一條select * from table_name where id = {ID value} 這樣的SQL查詢數據庫，取出對應的數據對象，放入到結果列表，并把這個數據對象按照ID放入到緩存中。
(3) ID查詢的時候，Jive執行類似第(2)步的過程，先從緩存中查找該ID，查不到，再查詢數據庫，然后把結果放入到緩存。
(4) 刪除、更新、增加數據的時候，同時更新緩存。
2．Jive緩存策略的優點：
(1) ID查詢的時候，如果該ID已經存在于緩存中，那么可以直接取出。節省了一條數據庫查詢。
(2) 當多次條件查詢的結果集相交的情況下，交集里面的數據對象不用重復從數據庫整個獲取，直接從緩存中獲取即可。
比如，第一次查詢的ID列表為{1, 2}，然后根據ID列表的ID從數據庫中一個一個取出數據對象，結果集為{a(id = 1), b(id = 2)}。
下一次查詢的ID列表為{2, 3}，由于ID = 2的數據對象已經存在于緩存中，那么只要從數據庫中取出ID = 3的數據對象即可。
3．Jive緩存策略的缺點：
(1) 在根據條件查找數據對象列表的過程中，DAO的第(1)步用來獲得ID列表的那一次數據庫查詢，是必不可少的。
(2) 如果第(1)步返回的ID列表中有n個ID，在最壞的命中率（緩存中一個對應ID都沒有）情況下，Jive還要再查詢n次數據庫。最壞情況下，共需要n + 1數據庫查詢。

二、Hibernate的二級緩存策略
Hibernate用Session類包裝了數據庫連接從打開到關閉的過程。
Session內部維護一個數據對象集合，包括了本Session內選取的、操作的數據對象。這稱為Session內部緩存，是Hibernate的第一級最快緩存，屬于Hibernate的既定行為，不需要進行配置(也沒有辦法配置 :-)。
Session的生命期很短，存在于Session內部的第一級最快緩存的生命期當然也很短，命中率自然也很低。當然，這個Session內部緩存的主要作用是保持Session內部數據狀態同步。
如果需要跨Session的命中率較高的全局緩存，那么必須對Hibernate進行二級緩存配置。一般來說，同樣數據類型（Class）的數據對象，共用一個二級緩存（或其中的同一塊）。
1．Hibernate二級緩存策略的過程描述：
(1)條件查詢的時候，總是發出一條select * from table_name where …. （選擇所有字段）這樣的SQL語句查詢數據庫，一次獲得所有的數據對象。
(2) 把獲得的所有數據對象根據ID放入到第二級緩存中。
(3) 當Hibernate根據ID訪問數據對象的時候，首先從Session一級緩存中查；查不到，如果配置了二級緩存，那么從二級緩存中查；查不到，再查詢數據庫，把結果按照ID放入到緩存。
(4) 刪除、更新、增加數據的時候，同時更新緩存。

2．Hibernate二級緩存策略的優點：
(1) 具有Jive緩存策略同樣的第(1)條優點：ID查詢的時候，如果該ID已經存在于緩存中，那么可以直接取出。節省了一條數據庫查詢。
(2) 不具有Jive緩存策略的第(2)條缺點，即hibernate不會有最壞情況下的 n + 1次數據庫查詢。
3．Hibernate二級緩存策略的缺點：
(1) 同Jive緩存策略的第(1)條缺點一樣，條件查詢的時候，第(1)步的數據庫查詢語句是不可少的。而且Hibernate選擇所有的字段，比只選擇ID字段花費的時間和空間都多。
(2) 不具備Jive緩存策略的第(2)條優點。條件查詢的時候，必須把數據庫對象從數據庫中整個取出，即使該數據庫的ID已經存在于緩存中。

三、Hibernate的Query緩存策略
可以看到，Jive緩存和Hibernate的二級緩存策略，都只是針對于ID查詢的緩存策略，對于條件查詢則毫無作用。（盡管Jive緩存的第(2)個優點，能夠避免重復從數據庫獲取同一個ID對應的數據對象，但select id from …這條數據庫查詢是每次條件查詢都必不可少的）。
為此，Hibernate提供了針對條件查詢的Query緩存。
1．Hibernate的Query緩存策略的過程描述：
(1) 條件查詢的請求一般都包括如下信息：SQL, SQL需要的參數，記錄范圍（起始位置rowStart，最大記錄個數maxRows)，等。
(2) Hibernate首先根據這些信息組成一個Query Key，根據這個Query Key到Query緩存中查找對應的結果列表。如果存在，那么返回這個結果列表；如果不存在，查詢數據庫，獲取結果列表，把整個結果列表根據Query Key放入到Query緩存中。
(3) Query Key中的SQL涉及到一些表名，如果這些表的任何數據發生修改、刪除、增加等操作，這些相關的Query Key都要從緩存中清空。
2．Hibernate的Query緩存策略的優點
(1) 條件查詢的時候，如果Query Key已經存在于緩存，那么不需要再查詢數據庫。命中的情況下，一次數據庫查詢也不需要。
3．Hibernate的Query緩存策略的缺點
(1) 條件查詢涉及到的表中，如果有任何一條記錄增加、刪除、或改變，那么緩存中所有和該表相關的Query Key都會失效。
比如，有這樣幾組Query Key，它們的SQL里面都包括table1。
SQL = select * from table1 where c1 = ? …., parameter = 1, rowStart = 11, maxRows = 20.
SQL = select * from table1 where c1 = ? …., parameter = 1, rowStart = 21, maxRows = 20.
SQL = select * from table1 where c1 = ? ….., parameter = 2, rowStart = 11, maxRows = 20.
SQL = select * from table1 where c1 = ? ….., parameter = 2, rowStart = 11, maxRows = 20.
SQL = select * from table1 where c2 = ? …., parameter = ‘abc’, rowStart = 11, maxRows = 20.

當table1的任何數據對象（任何字段）改變、增加、刪除的時候，這些Query Key對應的結果集都不能保證沒有發生變化。
很難做到根據數據對象的改動精確判斷哪些Query Key對應的結果集受到影響。最簡單的實現方法，就是清空所有SQL包含table1的Query Key。

(2) Query緩存中，Query Key對應的是數據對象列表，假如不同的Query Key對應的數據對象列表有交集，那么，交集部分的數據對象就是重復存儲的。
比如，Query Key 1對應的數據對象列表為{a(id = 1), b(id = 2)}，Query Key 2對應的數據對象列表為{a(id = 1), c(id = 3)}，這個a就在兩個List同時存在了兩份。

4．二級緩存和Query緩存同步的困惑
假如，Query緩存中，一個Query Key對應的結果列表為{a (id = 1) , b (id = 2), c (id = 3)}; 二級緩存里面有也id = 1對應的數據對象a。
這兩個數據對象a之間是什么關系？能夠保持狀態同步嗎？
我閱讀Hibernate的相關源碼，沒有發現兩個緩存之間的這種同步關系。
或者兩者之間毫無關系。就像我上面所說的，只要表數據發生變化，相關的Query Key都要被清空。所以不用考慮同步問題？

四、Lightor的緩存策略
Lightor是我做的Java開源持久層框架。Lightor的意思是，Lightweight O/R。Hibernate，JDO，EJB CMP這些持久層框架，都是Layer。Lightor算不上Layer，而只是一個Helper。這里的O/R意思不是Object/Relational，而是Object/ResultSet的意思。:-)
Lightor的緩存策略，主要參照Hibernate的緩存思路，Lightor的緩存也分為 Query緩存和ID緩存。但其中有一點不同，兩者之間并不是毫無聯系的，而是相互關聯的。
1．Lightor的緩存策略的過程描述：
(1) 條件查詢的請求一般都包括如下信息：SQL, 對應SQL的參數，起始記錄位置(rowStart)，最大記錄個數(maxRows)，等。
(2) Lightor首先根據這些信息組成一個Query Key，根據這個Query Key到Query緩存中查找對應的結果ID列表。注意，這里獲取的是ID列表。
如果結果ID列表存在于Query緩存，那么根據這個ID列表的每個ID，到ID緩存中取對應的數據對象。如果所有ID對應的數據對象都找到，那個返回這個數據對象結果列表。注意，這里獲取的是整個數據對象（所有字段）的列表。
如果結果ID列表不存在于Query緩存，或者結果ID列表中的某一個ID不存在于ID緩存，那么，就查詢數據庫，獲取結果列表。然后，把獲取的每個數據對象按照ID放入到ID緩存；并組裝成一個ID列表，按照Query Key存放到Query緩存中。注意，這里是把ID列表，而不是整個對象列表，放入到Query緩存中。
(3) ID查詢的時候，Lightor先從ID緩存中查找該ID，如果不存在，那么查詢數據庫，把結果放入ID緩存。
(4) Query Key中的SQL涉及到一些表名，如果這些表的任何數據發生修改、刪除、增加等操作，這些相關的Query Key都要從緩存中清空。
2．Lightor的緩存策略的優點
(1) Lightor的ID緩存具有Jive緩存，和Hibernate二級ID緩存的優點。ID查詢的時候，如果該ID已經存在于緩存中，那么可以直接取出。節省了一條數據庫查詢。
(2) Lightor的Query緩存具有Hibernate的Query緩存的優點。條件查詢的時候，如果Query Key已經存在于緩存，那么不需要再查詢數據庫。命中的情況下，一次數據庫查詢也不需要。
(3) Lightor的Query緩存中，Query Key對應的是ID列表，而不是數據對象列表，真正的數據對象只存在于ID緩存中。所以，不同的Query Key對應的ID列表如果有交集，ID對應的數據對象也不會在ID緩存中重復存儲。
(4) Lightor的緩存也沒有Jive緩存的最壞情況n + 1次數據庫查詢缺點。
3．Lightor的緩存策略的缺點
(1) Lightor的Query緩存具有Hibernate的Query緩存的缺點。條件查詢涉及到的表中，如果有任何一條記錄增加、刪除、或改變，那么緩存中所有和該表相關的Query Key都會失效。
(2) Lightor的ID緩存也具有hibernate的二級ID緩存具有的缺點。條件查詢的時候，即使ID已經存在于緩存中，也需要重新把數據對象整個從數據庫取出，放入到緩存中。

五、Query Key的效率
Query緩存的Query Key的空間和時間開銷比較大。
Query Key里面存放的東西不少，SQL, 參數，范圍（起始，個數）。
這里面最大的東西就是SQL。又占地方，又花時間（hashCode, equals）。
Query Key最關鍵的兩個方法是hashCode和equals，重點是SQL的hashCode和equals。

Lightor的做法是，由于Lightor直接使用SQL，不用HQL、OQL之類，所以推薦盡量使用static final String的SQL，能夠節省空間和時間，以至于Query Key的效率能夠相當于ID Key的效率。
至于Hibernate的QueryKey，有興趣的讀者可以去下載閱讀Hibernate的各個版本的源代碼，跟蹤一下QueryKey的實現優化過程。

六、總結
這里列一個表，綜合表示Jive, Hibernate, Lightor的緩存策略的特征。
N + 1問題 重復ID緩存問題 Query緩存支持
Jive緩存 有 無 不支持
Hibernate緩存 無 有 支持
Lightor緩存 無 有 支持

注：
“重復ID緩存問題”的含義是，每次條件查詢，不是只取ID列表，而是取出完整對象（所有字段）的列表。這樣，同一個ID對應的數據對象，即使在緩存中已經存在，也可能被重新放入緩存。參見相關緩存的缺點描述。
“重復ID緩存問題”的負面效應到底有多大，就看你的select id from …（只選擇ID）比你的 select * from … (選擇所有字段)快多少。主要影響因素是，字段的個數，字段值的長度，與數據庫服務器之間網絡傳輸速度。
不管怎么說，即使選擇所有字段，也只是一次數據庫查詢。而N + 1問題帶來的可能最壞的負面效應（N + 1次數據查詢）卻是非常大的。
選擇緩存策略的時候，應根據這些情況發生的概率和正負面效應進行取舍。

----- added later

看到Robbin在04年6月的一篇相關文章。

Hibernate Iterator JCS分析
http://www.hibernate.org.cn/71.html