現在搜狐新聞上報道已經有700多人傷亡，這是自從911事件以后最大的一次恐怖襲擊了。現在這個世界，是越來越不太平了，貧富差距的加大使得恐怖活動有生存的土壤。
      不知道世界的經濟會不會隨著這次恐怖襲擊而開始走向蕭條。現在的地球越來越像一個村，發生在任何一個角落的事情，都有可能會影響到每一個人。

      昨晚偶然看見國際臺播放星戰的作者喬治盧卡斯榮獲AFI終身成就獎的頒獎典禮，耐心的看完了整個頒獎典禮。喬治在發表致詞的時候，說自己很高興能夠從事自己喜歡的電影工作，如果不拍攝電影，都不知道自己還能夠做什么。拍電影已經成了喬治生命的一部分。
      看到熒屏上全世界的老人，中年人，年輕人，孩子說著：“Thank you! George.”可以看到喬治的眼睛朦朧。我心中真是感慨，每個人都有自己的夢想，能夠從事自己喜歡的事情，確實是很開心的一件事。而自己所做的工作，能夠給自己帶來快樂，能夠給人們帶來快樂，這樣的工作才值得用一生的時間去從事。
      每一個登山者都有著自己心目中最想登上的山頂，能夠登上這個山頂，前面付出的艱辛都是值得的。人生不也如此么？找到自己喜歡從事的事情，用自己畢生的精力去做這件事。

獻出一份愛心 共同援助重病程序員王俊

(2005.06.27)   來自：BJUG

向IT界倡議：援助程序員王俊行動 王俊，今年27歲，北京北方銀證公司項目經理，是北京Java用戶組（BJUG， 員（http://forum.javaeye.com/profile.php?mode=viewprofile&u=33）。一個年輕 人，有感興趣的工作，不錯的前途，還有一群可以隨時交流技術的朋友，生活看起來平 淡卻充實。 業余時間，王俊經常還利用blog（http://befresh.blogbus.com）寫下自己生活和工作 中的酸甜苦辣，此外他還有一個并不富裕但卻很溫馨的家。 然而從今年二月份起，王俊的blog就再也沒有更新過了，他也沒有在BJUG的聚會和 javaeye出現了，所有人都以為他出差去了。直到最近，驚聞他要換骨髓，才知道今年 年初，王俊被查出患有“骨髓增生異常綜合癥”。 骨髓增生異常綜合征目前認為是造血干細胞增殖分化異常所致的造血功能障礙。主要表 現為外周血全血細胞減少，骨髓細胞增生，成熟和幼稚細胞有形態異常即病態造血。部 分患者在經歷一定時期的MDS后轉化成為急性白血病；部分因感染、出血或其他原因死 亡，病程中始終不轉化為急性白血病。 這種病目前最有效的治療手段是換骨髓。萬幸的是，王俊的妹妹和他的骨髓配型一致， 免疫系統的疾病發現治療的越早，就越可能成功，他目前的身體狀況還好，只要能更換 骨髓，完全可以康復！但讓他們一家望而卻步的是，僅手術押金就需要20萬，全部療程 視治療效果可能需要30-100萬。 王俊的家在浙江杭州千島湖，父母都是農民，已然老邁且沒有固定的經濟收入，姐姐在 當地出嫁，收入頗低，妹妹目前在北京讀成人教育并在公司打工。王俊是家庭經濟主要 來源，他的病不僅掐斷了家里唯一的經濟來源，還要花上對他們而言是天文數字的錢來 治病。 "文章千古事，得失寸心知"，這是王俊blog上的座右銘。細細翻看這個典型程序員的 blog，就和他的人一樣樸實無華，在那里滿眼看到的都是對技術的孜孜追求。誰能想到 一個如此活躍的頭腦現在卻被病魔折磨著。 生命是美好的，這世界每天都有若干悲劇發生，這次，大家每個人出一份力，這世界就 會少一個悲劇，多一份美好，多一份歡笑。也許，你只是少吃一頓大餐，少買一瓶化妝 品，少看一場演唱會，少買一件名牌服裝，少玩一個月的網絡游戲，少上一個月的網， 但是你卻可以為一個家庭托起一份生的希望。 ***** 聯系方式  郵件 help@bjug.org MSN  icecloud@sina.com 冰云(BJUG)  援助辦法： 1 捐款 帳號： 工商銀行 戶名 王俊 帳號 0200 2008 0102 3428 807 開戶行 工商銀行北京市西內所 招商銀行 戶名 王俊 帳號 9555 5001 0200 2820 開戶行 招商銀行 北京分行 中國銀行 戶名 王俊 帳號 4021400-0188-001204-0 開戶行 北京西直門支行 國外匯款方式 ADD: BANK OF CHINA BEIJING BRANCH NO.8 YA BAO LU BEIJING, CHINA SWIFT-CODE: BKCHCNBJ110 A/CNo: 4021400-0188-001204-0 NAME: WANG JUN 捐款方式： A 網上銀行 工行請采用行內匯款->有收款帳號匯款 招行請采用個人銀行專業版的同城轉帳/異地匯款，并選中：采用系統內快速匯款 B 銀行匯款 請抄錄上述帳號并到銀行填寫匯款單 請在捐款后，發郵件至help@bjug.org，通知我們，以便統計核對捐款帳目。郵件中請說明以下信息：  (1) 姓名， (2) id/網站, (3) 發出銀行/發出帳號， (4) 金額， (5) 時間 2 幫助宣傳： 請到http://befresh.bjug.org 留下你對他的祝福 請在MSN上修改您的名字，我們都寫上 [祝福后山] 請修改您MSN的頭像為我們提供的圖標 增加行動網站的地址 http://befresh.bjug.org 到MSN名字后面的個人信息 請看到此文的Blogger，在您的blog上link此文，并Trackback到后山的blog 請看到此信息的人，幫助一起宣傳，我們需要您的幫助 在您的BLOG或網站，加上用我們提供的LOGO，并連接到網站http://befresh.bjug.org 泡論壇的，請修改你的論壇LOGO和簽名檔為提供的圖標   ***** 聯合發起： BJUG http://www.bjug.org <http://www.bjug.org/>  CSDN http://www.csdn.net <http://www.csdn.net/>  JavaEye http://www.javaeye.com <http://www.javaeye.com/>  JActionGroup http://www.jactiongroup.net/ Huihoo http://www.huihoo.org <http://www.huihoo.org/>  RedSaga http://www.redsaga.com <http://www.redsaga.com/>   Matrix http://www.matrix.org.cn <http://www.matrix.org.cn/> Blogbus http://www.blogbus.com <http://www.blogbus.com/>

     摘要:       要將BufferedImage實例保存為BMP文件，就需要知道BMP文件的格式，可以參考我轉載的文章：《BMP文件格式》。      下面是我的將BufferedImage實例保存為24位色BMP文件的實現。     ...  閱讀全文       在公元2005年6月27日，我做出了一個重大的決定，買房！花了自己至今為止都沒有見過的那么多的錢買了一個小小的2房2廳， 從此變成了“負翁”。
      不過，從此以后再也不用去租房，再也不用幫別人供房，再也不用一年搬一次家。深圳租房實在太貴，蓮花北的一個小小的二房都要1800，有點裝修就叫豪華裝修，就是一個空蕩蕩的房子也開口要1500，太夸張了。住農民房又極度不安全，不想拿自己的生命開玩笑。
      從此就變成月供一族了，，不過，有了壓力才有動力。為了自己的將來，自己的理想，努力奮斗！
      9月26日是入伙的日子，好期待那天的到來啊。       一般而言，ORM的數據緩存應包含如下幾個層次：
      1. 事務級緩存（Transcation Layer Cache）
      2. 應用級/進程級緩存（Application/Process Layer Cache）
      3. 分布式緩存（Cluster Layer Cache）

      Hibernate數據緩存（Cache）分為兩個層次，以Hibernate語義加以區分，可分為：
      1. 內部緩存（Session Level，也稱為一級緩存）
      2. 二級緩存（SessionFactory Level，也稱為二級緩存）

      Hibernate中，緩存將在以下情況中發揮作用：
      1. 通過id[主鍵]加載數據時
      2. 延遲加載

      內部緩存正常情況下由Hibernate自動維護，如果需要手動干預，可以通過以下方法完成：
      1. Session.evict
         將某個特定對象從內部緩存清除。
      2. Session.clear
         清空內部緩存。

      在Hibernate中，二級緩存涵蓋了應用級緩存和分布式緩存領域。如果數據滿足以下條件，則可將其納入緩存管理。
      1. 數據不會被第三方應用修改；
      2. 數據大小(Data Size)在可接收的范圍之內；
      3. 數據更新頻率較低；
      4. 同一數據可能會被系統頻繁引用；
      5. 非關鍵數據(關鍵數據，如金融帳戶數據)。
      Hibernate本身并未提供二級緩存的產品化實現，而是為眾多的第三方緩存組件提供了接入接口，較常用的第三方組件有：
      1. JCS
      2. EHCache
      3. OSCache
      4. JBossCache
      5. SwarmCache
      Hibernate中啟用二級緩存，需要在hibernate.cfg.xml配置hibernate.cache.provider_class參數，之后，需要在映射文件中指定各個映射實體(以及collection)的緩存同步策略。Hibernate提供了一下4種內置的緩存同步策略：
      1. read-only
         只讀。對于不會發生改變的數據，可使用只讀型緩存。
      2. nonstrict-read-write
         如果程序對并發訪問下的數據同步要求不是非常嚴格，且數據更新操作頻率較低，可以采用本選項，獲得較好的性能。
      3. read-write
         嚴格可讀寫緩存。基于時間戳判定機制，實現了“read committed”事務隔離等級。可用于對數據同步要求嚴格的情況，但不支持分布式緩存。這也是實際應用中使用最多的同步策略。
      4. transactional
         事務型緩存，必須運行在JTA事務環境中。

      在Java語言中，對象之間的比較可以通過引用比較(==)和內容比較(equals)兩種方式進行，而在Hibernate的實體對象的比較是通過主鍵值來比較，如果要實現自己的識別邏輯，則需要重寫equals方法和hashCode方法。

      檢查數據對象改變檢查的一般策略有下面兩種：
      1. 數據對象監控
         數據對象監控的實現方式，通過攔截器對數據對象的設值方法進行攔截。一旦數據對象的設置方法被調用，則將其標志為“待更新”狀態，之后在數據庫操作時將其更新到對應的庫表。
      2. 數據版本對比
         在持久層框架中維持數據對象的最近讀取版本，當數據提交時將提交數據與此版本進行比對，如果發生變化則將其同步到數據庫對應的庫表。

      Hibernate采取的是第二種檢查策略。它采用一個內部數據結構"EntityEntry"保存對應實體類的狀態信息。

      對于級聯對象的更新，Hibernate將根據unsaved-value進行判定。首先Hibernate會取出目標對象的id。之后，將此值與unsaved-value進行比對，如果相等，則認為目標對象尚未保存，否則，認為對象已經保存，無需再進行保存操作。

      最近正在研讀《深入淺出Hibernate》一書，前面寫的隨筆有些也是讀該書的筆記，只是未做歸類，從這篇開始，我將把相關的內容都整理成一個系列的讀書筆記。
      今天這篇是有關實體對象的生命周期。我剛開始接觸Hibernate的時候，只是簡單的把它當做一個API工具，直到后來看到有關VO和PO的內容時，才意識到Hibernate不僅僅是一個O/R Mapping的API工具，它還是一個容器。它可以幫你管理實體對象的生命周期。

      實體對象的生命周期有三種狀態：
      1.Transient（自由狀態）
      此時的實體對象和數據庫中的記錄無關聯，只是一個普通的JavaBean。
      2.Persistent（持久狀態）
      此時的實體對象和數據庫中的記錄有關聯，其變更將由Hibernate固化到數據庫中。該實體對象處于由Hibernate框架所管理的狀態。
      3.Detached（游離狀態）
      處于Persistent狀態的對象，其對應的Session實例關閉之后，那么，此對象就處于"Detached"狀態。Detached狀態和Transient狀態的區別在于Detached狀態的對象可以再次與某個Session實例相關聯而成為Persistent對象。

      從實體對象是否被納入Hibernate實體管理容器的角度，Transient和Detached狀態的實體對象可以統稱為VO（Value Object），而被管理的實體對象稱為PO（Persistent Object）。兩者的區別：
      1.VO是相對獨立的實體對象，處于非管理狀態。
      2.PO是Hibernate納入其實體管理容器（Entity Map）的對象，它代表了與數據庫中某條記錄對應的Hibernate實體，PO的變化在事務提交時將反映到實際數據庫中。
      3.如果一個PO與其對應的Session實例分離，那么此時，它又會變成一個VO。

      下圖是我畫的實體對象生命周期的狀態轉換圖：

      在使用HQL查詢中，有時并不需要獲取完整的一個實體對象，例如一個實體對象User有三個屬性：account, password和email，如果我們只需要獲取account和email屬性，那么有兩種方法可以選擇。
      1. 用普通的"select user.account, user.email from User as user"，程序片斷如下：


      這時調用Query類的list方法返回的將是一個每個元素都是一個Object數組的List。如果只獲取一個屬性，那么返回的List中的每個元素都是String實例。

      2.在HQL中用new操作符生成實體對象，例如："select new User(user.account, user.email) from User as user"，程序片斷如下：


      這時list方法返回的List中的每一個元素都是User實體對象。這里有三點需要注意的：
      a.在HQL語句中需要使用as操作符指定User的別名，并且需要在構造函數的屬性前面加上別名；
      b.HQL語句中的構造函數在User類中必須要有相應的構造函數；
      c.生成的實體對象是VO對象，如果對這些對象調用Session的saveOrUpdate方法將導致插入新的記錄，而不是更新記錄。       JBuilder 2005中多了一個Smart MemberInsight功能，這個功能會智能的匹配需要調用的方法或者獲取的屬性。例如有一個賦值操作，左邊是一個List，右邊是用一個方法獲取值，那么當輸入"."時，JBuilder 2005會自動的找到所有返回的值為List的方法。
      不過，這實在是一個不怎么討好的方法。因為很多時候并不是只有一層方法調用的，例如，當需要用一個方法獲取一個實例，然后再用這個實例的方法獲取需要的值時，這個功能就顯得很礙手了。
      終于，我還是決定關閉這個“智能”的功能。打開"Tools"——>"Preferences"，在"Editor"的子項"CodeInsight"里，展開"MemberInsight"，把"Default to Smart MemberInsight"這一項去掉。如下圖所示：