其他

 瑪雅預言，世界止於2012. 曾和女孩戲稱自己要去當和尚， 卻沒有女孩為我傷心， 雖在預料之中，卻也在情理之外， 我的處境是何其多麼的慘呢！ 直慘過小強。冤過竇娥。 我的慘，已經超越物種，超越三界了。 眾位MM們，不對，親，你還單身嗎？ 請原諒我略帶邪惡的竊喜， 請原諒我發自肺腑的幸災樂禍， 因為那也是我卑微的真情流露， 因為再卑微，也嚮往幸福，快樂， 因為我也單著。。。   浙江省杭州市靈隱寺招聘和尚   待遇：4000/月，8小時工作制，包吃包住，出差上門做法事，按小時發放出差補貼。  

解決戴爾15R切換大小寫游標延時的問題進入登錄編輯程式：在運行裡輸入‘regedit’，如果沒有運行，在搜尋 裡輸入也行，只要找到登錄編輯程式就行，然後開啟，按照上述操作。1.在360軟體管理中的進階設定中的開機加速中把QUICKSET這個軟體取消。      2.修改下面的註冊表索引值為 30d40 (16進位)：        HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout   

關於資料庫連結我們所說有JDBC進階應用程式,並不是說它的技術含量很高(也許JAVA平台上不存在什麼"技術含量"的說法,因為JAVA是給大家用的而不是給某些人用的).說它是進階應用程式,是因為它是對於JDBC基礎應用來說的擴充,也就是可以最佳化你的應用效能,或方便於應用的實現.所以說它是一種進階應用程式而不叫進階技術.    JDBC中,java.sql包是基礎的,也是核心的功能,javax.sql包則是進階的,擴充的功能.所以為了交流的方便,我們把它們區分為core API和optional 

JDBC進階應用程式(二)本來想繼續談JDBC的進階連結方式,事務模式.但發現關於大Object Storage Service有很多人在問,所以先來插入一節關於大Object Storage Service的內容,然後再接著原來的思路寫下去.JDBC的大Object Storage

對於一個存諸過程,如果返回的結果是我們預Crowdsourced Security

    在前面的介紹中,我們可以看出, DataSource才能提供最高效能的對資料庫的並發訪問,但是,對DataSource的引用,也還有很多知識要弄清楚,擷取Connection的方式是資料庫效能最相關的技術,而對DataSource的調用對資料庫效能起著很大的決定作用。    一般對於DataSource的引用是通過以下流程來進行：            Context ct = new InitialContext();            DataSource ds = (DataS

在沒有開始JDBC分散式交易前,先來回顧一下J2EE平台的資料來源的整體構加:在上面的介紹中,可能大家會過於限入理解如何?ConnectionPoolDataSource和PooledConnection,而忘記了它的整體結構.為了協助大家更快地理解,我從以下幾點進行總結.聲明:本文完全是作者根據SUN的文檔從實踐中總結,沒有參考(事實上目前我還沒有找到這方面的參考)任何文章:1.    DataSource和ConnectionPoolDataSource,PooledConnection,C

轉載地址： http://wenku.baidu.com/view/51326241336c1eb91a375d41.html代碼” ${pageContext.request.contextPath}”的作用是取出部署的應用程式名稱，這樣不管如何部署，所用路徑都是正確的。一．問題    JSP中究竟採用絕對路徑還是採用相對路徑隨著所採用技術的越來越複雜，這個問題也變得越來越難以解決。１）採用相對路徑遇到的問題l        

這幾天做管理工具,有一個操作很令人頭痛. 當插入一條記錄時,我們很多時候都想馬當前插入的主鍵返回出來.作為另一個操作的條件.如果主鍵是自動產生的(大多數時候是這樣),那麼取回主鍵是一種比較困難的事.可能對於一些特殊的資料庫必須把insert into和select max(key)或什麼序列當前值作為一個事務的原子來操作,但很多資料庫(以及資料庫作業環境)並不能為你提供事務並發控制.所以如果多人同時操作,那麼select max(key)很可能就不是你剛才insert的那條記錄. 在JDBC3.

今天再次在衛琴的論壇上看到有人問這樣的問題:short    tmp = 0;為什麼tmp = tmp +1;錯誤但 tmp

之前的版本中對於jps需要讀取的檔案，JVM啟動時寫入的固定的目錄 %TMP%或$TMP下的hsperfdata_usrname/$pid但是對於jdk16_23/24 bug，這個檔案路徑根據-Djava.io.tmpdir來寫入。但JPS卻不知道去哪裡尋找這個檔案，仍然會去/tmp/hsperfdata_usrname下面尋找進程號，所以如果你的JVM啟動時修改了Djava.io.tmpdir,那麼JPS就會尋找出錯誤的進程號。  這個問題我已經提交了bug

JDBC進階應用程式三再談JDBC連結為什麼要反覆談JDBC連結,因為所以JDBC的效能,最主要的就是JDBC連結,而SQL語句的最佳化,和JAVA編程無關,你的一個查詢語句的效率,是你對於SQL文法的提示,這一方面你就可請教DBA,而不是來看我這種程式設計者的文章.我們已經知道,取得資料庫連結,有幾種層次的實現方法,一是直接得到物理連結,而是通過傳統的連結池(沒有多大區別),三是通過java的擴充包javax.sql.DataSource得到連結控制代碼,對於上面兩種,沒有什麼可以多說的,對於

volatile 變數volatile 是用來保證[記憶體同步]的關鍵字,記憶體同步是說在某個線程中修改某執行個體欄位能夠及時地更新到主儲存區,而某線程如果需要引用該欄位也能及時地從主儲存區中得到最新的資料.簡單說它是當前線程的工作儲存區和主儲存區對某欄位的及時同步,所以我們說它是[記憶體同步],但它不是線程同步.也就是說,一個線程對

深入理解線程對象和線程讓我們先以C++來說明,然後我們轉到JAVA上來,因為c++對對象的銷毀更直接一些:到目前為止,C++還沒有直接支援多線程,意思是說多線程不是C++標準庫,這也是JAVA程式員對於多線程編程比C++程式更精通一些(這是普通來說的,你不要拿一個C++多線程高手和普通的JAVA程序員比),因為JAVA程式從一開始就接收了多線程的思想並不斷地訓練.目前最有可能被下一代C++標準採用的多線程庫是ZThread,或者我們可以直接用VC的CWinThread來舉例,它們都是標準C++上

在JDBC應用中,如果你已經是稍有水平開發人員,你就應該盡量以PreparedStatement代替Statement.也就是說,在絕大多數時候都不要使用Statement.基於以下的原因:一.代碼的可讀性和可維護性.雖然用PreparedStatement來代替Statement會使代碼多出幾行,但這樣的代碼無論從可讀性還是可維護性上來說.都比直接用Statement的代碼高很多檔次:stmt.executeUpdate("insert into tb_name (col1,col2,col2

 做了一個java5.0/6.0的反編譯工具.隨意試用吧.其實就是做了一個外殼.對class檔案修改版本後調用jad來反編譯.調用jad的過程用SW_SHOW顯示到前台,目的是為了目標檔案中已經存在相同的java檔案,比如上一次已經反編譯了一次,沒有刪除時,jad提示要覆蓋,如果在後台沒有手工確認jad進程就死在進程列表中了.最好是在反編譯前前目標檔案夾清空.另外沒有將臨時檔案夾自動清空是因為在迴圈調用ShellExecute時,WaitForSingleObject仍然會產生衝突.而且程式遞迴

 在我和一些朋友深入討論"底層"的技術細節時,經常被一些"超級大師"(火星來的)諷刺為造輪子,我總是淡然一笑.因為說你在幹什麼事只是說了一個事實,而這個世界並沒有任何標準來評判這個行為是否正確,也許只有上帝知道.  別人已經發明的輪子我們是否還需要造? 當然需要,就在某些諷刺我們在造輪子的"大師們"的言論中竟然還會加上一兩句:中國的IT技術就是因為你們這行人才永遠趕不上別人. 看看這種前後矛盾的大師觀點,既然反對造輪子,那麼很多技術已經被別人發明了,中國為什麼還要再去造一次輪子?如此說來,龍芯這

深入理解JMM的重點JMM具體規定要JLS的 "Thread and lock"一章中,可以說這是一章非常晦澀的一個規範,要想完全把它理解清楚,一般的辛苦是不行的.那是要"相當的~~~"的辛苦.而要把它向別人再解釋清楚,那簡直就是惡夢.作者自知無力能全面清楚地向大家說明這一章的內容,但以作者的經驗,主要從以下兩個方面去理解可以改快地抓住本質.而不至於陷入"Thread and

 使用HibernateTemplate的方法進行CRUD操作,其中查詢操作通常可分為兩種，一種為固定條件查詢，另一種為動態多條件查詢（如查詢介面的實現），固定條件查詢可以很方便地通過createQuery,find()等方法實現，但是我在動態條件查詢的實現過程中，hibernate3.0可以實現英文的條件查詢，而中文條件則會出現亂碼。現將具體的流程說明如下：      1.固定條件查詢   

想做架構師,要把你的思維從功能轉變到效能上.如果連功能都實現不了,那先老老實實做你的程式員,多鍛練幾年吧.程式員的基礎知識積累到一定程度,幾乎沒有什麼是不能做的.我說幾乎是指有些特別的"核心技術"不是靠技術能力能接觸到的,這部分的東西一般人是做不了的.我們不把它作為通用的內容來討論.你幾乎什麼都能做了,你最關心的是什麼?是你能做多少?說實話我提出這個問題會有很多人反駁我,因為也有很多做案頭應用的程式員,他們很少或從來不關心效能問題.因為他們的程式裝在案頭機上,只有一個使用者在和程式互動.他們的程