最近在弄swing，需要由JComponent生成BufferedImage，在CSDN上發現一個好例子。下面是范例：


這樣，JComponent中的圖像就保存到BufferedImage中了。
原文的鏈接：http://dev.csdn.net/article/13/13531.shtm

??????? 好久沒有寫blog了，距離上次寫幾乎已經是半年前的事情了。?這半年發生了不少事情。首先換了家公司，進了家金融企業，每天要西裝革履的，一開始還真是不習慣。?這里開發是用的spring框架，以后要多研究研究spring的東西了。
??????? 第二件事就是和戀愛了三年的女友結婚了，從此兩人長相廝守，不知道時間久了會不會審美疲勞。呵呵。
??????? 第三件事就是在深圳買了自己的小房子，雖然是小小的兩房，不過我們已經很知足了。?而且剛好是趕在房價大漲前買的，還算走了點運氣。換到現在，都不知道去哪里買好了。
??????? 在這里要向一些留言和發郵件給我的網友道歉，前段時間實在是太忙，沒有空回復你們的信息和郵件。請原諒！

      最近真是多事情忙，而且可能要忙到9月底。好久沒有上來更新我的博客了，暫且發發牢騷。

      這一節是非常實用的一節，我在閱讀此書的時候，一直在迷惑，究竟應該怎樣管理Session呢？因為Session的管理是如此重要，類似于以前寫程序對JDBC Connection的管理?？赐甏斯澓?，終于找到了方法。
      在各種Session管理方案中，ThreadLocal模式得到了大量使用。ThreadLocal是Java中一種較為特殊的線程綁定機制。通過ThreadLocal存取的數據，總是與當前線程相關，也就是說，JVM為每個運行的線程，綁定了私有的本定實例存取空間，從而為多線程環境經常出現的并發訪問問題提供了一種隔離機制。
      下面是Hibernate官方提供的一個ThreadLocal工具：


      針對WEB程序，還可以利用Servlet2.3的Filter機制，輕松實現線程生命周期內的Session管理。下面是一個通過Filter進行Session管理的典型案例：

      數據分頁顯示，是很多B/S系統會遇到的問題。現在大多數主流數據庫都提供了數據部分讀取機制，而對于某些沒有提供相應機制的數據而言，Hibernate也通過其它途徑實現了分頁，如通過Scrollable ResultSet，如果JDBC不支持Scrollable ResultSet，Hibernate也會自動通過ResultSet的next方法進行記錄定位。Hibernate的Criteria、Query等接口提供了一致的方法設定分頁范圍。下面是書中的例子：


      不過，我在測試的時候總是不能夠正常工作，把setFetchSize方法換成setMaxResults方法才行。換成最新的mysql-connector-java-3.1.10-bin-g.jar驅動也是一樣。

      Hibernate通過Lifecycle、Validatable接口制定了實體對象CRUD過程中的回調方式。
      Lifecycle接口中的onSave、onUpdate、onDelete方法，如果返回true則意味著需要中止執行相應的操作過程。如果代碼運行期間拋出了CallbackException，對應的操作也會被中止。注意，不要試圖在這些方法中調用Session進行持久化操作，這些方法中Session無法正常使用。
      Validatable.validate方法將在實體被持久化之前得到調用以對數據進行驗證。此方法在實體對象的生命周期內可能被數次調用，因此，此方法僅用于數據本身的邏輯校驗，而不要試圖在此實現業務邏輯的驗證。

---

      Hibernate還引入了Interceptor，為持久化事件的捕獲和處理提供了一個非侵略性的實現。Interceptor接口定義了Hibernate中的通用攔截機制。Session創建時即可指定加載相應的Interceptor，之后，此Session的持久化操作動作都將首先經由此攔截器捕獲處理。簡單的加載范例如下：

      需要注意的是，與Lifecycle相同，Interceptor的方法中不可通過Session實例進行持久化操作。

      有興趣的可以去參加看看，網址：http://www.javachina.cn/Index.jsp

      最近真是忙，事情都擠到一塊去了。 終于有時間又看了幾頁書。
      言歸正傳，Hibernate中的Collection類型分為有序集和無序集兩類。這里所謂的有序和無序，是針對Hibernate數據持久過程中，是否保持數據集合中的記錄排列順序加以區分的。無序集有Set，Bag，Map幾種，有序集有List一種。有序集的數據在持久化過程中，會將集合中元素排列的先后順序同時固化到數據庫中，讀取時也會返回一個具備同樣排列順序的數據集合。
      Hibernate中的Collection類型是用的自己的實現，所以在程序中，不能夠把接口強制轉化成相應的JDK Collection的實現。

---

      結果集的排序有兩種方式：
      1. Sort
         Collection中的數據排序。
      2. order-by
         對數據庫執行Select SQL時，由order by子句實現的數據排序方式。

      需要注意的是，order-by特性在實現中借助了JDK 1.4中的新增集合類LinkedHashSet以及LinkedHashMap。因此，order-by特性只支持在1.4版本以上的JDK中運行。

      Session.get/load的區別：
      1.如果未能發現符合條件的記錄，get方法返回null，而load方法會拋出一個ObejctNotFoundException。
      2.Load方法可返回實體的代理類類型，而get方法永遠直接返回實體類。
      3.Load方法可以充分利用內部緩存和二級緩存中現有數據，而get方法則僅僅在內部緩存中進行數據查找，如沒有發現對應數據，將越過二級緩存，直接調用SQL完成數據讀取。

---

      Session.find/iterate的區別：
      find方法將執行Select SQL從數據庫中獲得所有符合條件的記錄并構造相應的實體對象，實體對象構建完畢之后，就將其納入緩存。它對緩存只寫不讀，因此無法利用緩存。
      iterate方法首先執行一條Select SQL以獲得所有符合查詢條件的數據id，隨即，iterate方法首先在本地緩存中根據id查找對應的實體對象是否存在，如果緩存中已經存在對應的數據，則直接以此數據對象作為查詢結果，如果沒有找到，再執行相應的Select語句獲得對應的庫表記錄（iterate方法如果執行了數據庫讀取操作并構建了完整的數據對象，也會將其查詢結果納入緩存）。

---

      Query Cache產生作用的情況：
      1.完全相同的Select SQL重復執行。
      2.在兩次查詢之間，此Select SQL對應的庫表沒有發生過改變。

---

      Session.save方法的執行步驟：
      1.在Session內部緩存中尋找待保存對象。內部緩存命中，則認為此數據已經保存（執行過insert操作），實體對象已經處于Persistent狀態，直接返回。
      2.如果實體類實現了lifecycle接口，則調用待保存對象的onSave方法。
      3.如果實體類實現了validatable接口，則調用其validate()方法。
      4.調用對應攔截器的Interceptor.onSave方法（如果有的話）。
      5.構造Insert SQL，并加以執行。
      6.記錄插入成功，user.id屬性被設定為insert操作返回的新記錄id值。
      7.將user對象放入內部緩存。
      8.最后，如果存在級聯關系，對級聯關系進行遞歸處理。

---

      Session.update方法的執行步驟：
      1.根據待更新實體對象的Key，在當前session的內部緩存中進行查找，如果發現，則認為當前實體對象已經處于Persistent狀態，返回。
      2.初始化實體對象的狀態信息（作為之后臟數據檢查的依據），并將其納入內部緩存。注意這里Session.update方法本身并沒有發送Update SQL完成數據更新操作，Update SQL將在之后的Session.flush方法中執行（Transaction.commit在真正提交數據庫事務之前會調用Session.flush）。

---

      Session.saveOrUpdate方法的執行步驟：
      1.首先在Session內部緩存中進行查找，如果發現則直接返回。
      2.執行實體類對應的Interceptor.isUnsaved方法（如果有的話），判斷對象是否為未保存狀態。
      3.根據unsaved-value判斷對象是否處于未保存狀態。
      4.如果對象未保存（Transient狀態），則調用save方法保存對象。
      5.如果對象為已保存（Detached狀態），調用update方法將對象與Session重新關聯。

      事務的4個基本特性（ACID）：
      1. Atomic（原子性）：事務中包含的操作被看作一個邏輯單元，這個邏輯單元中的操作要么全部成功，要么全部失敗。
      2. Consistency（一致性）：只有合法的數據可以被寫入數據庫，否則事務應該將其回滾到最初狀態。
      3. Isolation（隔離性）：事務允許多個用戶對同一個數據的并發訪問，而不破壞數據的正確性和完整性。同時，并行事務的修改必須與其他并行事務的修改相互獨立。
      4. Durability（持久性）：事務結束后，事務處理的結果必須能夠得到固化。

---

      數據庫操作過程中可能出現的3種不確定情況：
      1. 臟讀?。―irty Reads）：一個事務讀取了另一個并行事務未提交的數據。
      2. 不可重復讀?。∟on-repeatable Reads）：一個事務再次讀取之前的數據時，得到的數據不一致，被另一個已提交的事務修改。
      3. 虛讀（Phantom Reads）：一個事務重新執行一個查詢，返回的記錄中包含了因為其他最近提交的事務而產生的新記錄。

      標準SQL規范中，為了避免上面3種情況的出現，定義了4個事務隔離等級：
      1. Read Uncommitted：最低等級的事務隔離，僅僅保證了讀取過程中不會讀取到非法數據。上訴3種不確定情況均有可能發生。
      2. Read Committed：大多數主流數據庫的默認事務等級，保證了一個事務不會讀到另一個并行事務已修改但未提交的數據，避免了“臟讀取”。該級別適用于大多數系統。
      3. Repeatable Read：保證了一個事務不會修改已經由另一個事務讀取但未提交（回滾）的數據。避免了“臟讀取”和“不可重復讀取”的情況，但是帶來了更多的性能損失。
      4. Serializable：最高等級的事務隔離，上面3種不確定情況都將被規避。這個級別將模擬事務的串行執行。

---

      Hibernate將事務管理委托給底層的JDBC或者JTA，默認是基于JDBC Transaction的。
      Hibernate支持“悲觀鎖（Pessimistic Locking）”和“樂觀鎖（Optimistic Locking）”。
      悲觀鎖對數據被外界修改持保守態度，因此，在整個數據處理過程中，將數據處于鎖定狀態。悲觀鎖的實現，往往依靠數據庫提供的鎖機制。Hibernate通過使用數據庫的for update子句實現了悲觀鎖機制。Hibernate的加鎖模式有：
      1. LockMode.NONE：無鎖機制
      2. LockMode.WRITE：Hibernate在Insert和Update記錄的時候會自動獲取
      3. LockMode.READ：Hibernate在讀取記錄的時候會自動獲取
      4. LockMode.UPGRADE：利用數據庫的for update子句加鎖
      5. LockMode.UPGRADE_NOWAIT：Oracle的特定實現，利用Oracle的for update nowait子句實現加鎖
      樂觀鎖大多是基于數據版本（Version）記錄機制實現。Hibernate在其數據訪問引擎中內置了樂觀鎖實現，可以通過class描述符的optimistic-lock屬性結合version描述符指定。optimistic-lock屬性有如下可選取值：
      1. none：無樂觀鎖
      2. version：通過版本機制實現樂觀鎖
      3. dirty：通過檢查發生變動過的屬性實現樂觀鎖
      4. all：通過檢查所有屬性實現樂觀鎖