讓IE8在Windows 7中運轉自如

Windows 7系統憑借其優越的安全和運轉性能逐漸吸引了越來越多的企業用戶,同時隨著原有Windows XP系統支持技術的缺失,大部分企業用戶開始轉而使用Windows 7系統。但是,這同時也意味著需要放棄IE6,使用升級的IE8,從而使得很多商務網頁程序無法正常使用。研究發現很多專門面向IE6設計的程序在IE8 下根本無法運行,不過微軟Windows應用程序體驗SWAT團隊技術主管Chris Jackson給出妙招,輕松解決Windows 7和IE8的兼容問題。

  英國媒體ZDNet UK近日就微軟Windows兼容問題參訪專家Jackson,並就如何解決第三方程序的兼容問題提問如下:

  問:微軟打算如何促使企業用戶放棄使用IE6?Windows 7在這方面有何作用?

  答:實際上大家還是習慣使用IE6,很多現有商務程序可以直接運行。很多用戶表示,壹旦使用Windows 7,就意味著不得不使用IE8,但是大部分人對其並不熟悉,市面上也沒有方便大家了解信息的材料。

  那麽您認為這僅僅是程序移植問題還是復雜的網頁開發項目?公司的IT或開發團隊是否需要在這方面多下功夫?

  有些程序可以通過簡單移植後直接使用,但可能還需要壹些專業人士修改壹部分代碼。但 是我們的IT團隊也確實應該對此項工作的難度有所把握。如果壹個程序開發員表示,“該項目將歷時17周”,那麽他的本意可能就是,“事實上,這就是更改某 些代碼的問題,我覺得妳能夠在17周內解決這個問題。”

  您認為在Windows 7下正常使用IE8最需要註意些什麽?

  最主要的是明確自己為什麽要用IE8。很多人在被問及此問題時,都會回答:“因為我 要使用Windows 7呀”。但事實上,如果不明確自己使用IE8的原因,壹旦產生了技術上的問題,很多人就會說,“我放棄了,我不是真的需要用IE8,看看有什麽方法能繼續 使用IE6呢?”但這並不是理想的瀏覽器。

  同時,在就兼容性問題作出決策時,如果用戶不明確自己看重IE的什麽特點,也就無法確知需要了解其什麽性能。例如,壹位用戶用IE8是看重它的安全性能,那麽壹旦出現問題而需要關閉或修復這些安全屬性時,用戶就會選擇對其原始代碼進行修復,而不是直接將其關閉了。

  企業用戶能否將網頁應用程序移植問題最簡化?

  根據已有的測試結果,用戶們往往對網頁應用程序的使用情況不是特別關註,例如微軟 IE7到IE8的升級中,為用戶所真正關註的程序只占總數的4%。對於其他的程序,我們則會告知用戶:這些程序或許能運轉正常,如果出現問題,請聯系客服 來解決,就像現在很多軟件常出現漏洞時的情況壹樣。那些需要關註的4%程序如果在壹整天內都無法正常使用,就意味著出現了問題。例如Outlook網絡版 如果無法正常使用,比如發送壹封郵件需要2小時,微軟就遇到了大問題。

  接下來就是決定如何使用這些程序。首要問題是:“我是否需要支持這些程序?”如果答 案是肯定的,那麽是否需要支持這個版本的程序?如果這次是否定的,那麽就買個新的吧。因為如果確實需要使用該程序,對已有的程序再進行測試是很費事的。壹 旦決定不支持,就會有很多選擇,或者重新設置,或者在網站上對編碼進行壹些修改,或者采取其他的權宜之計。最終的辦法很可能就是虛擬化,在兼容的操作系統 上運行IE6。

  那麽公司是否保證能對IE進行有效設置,避免用戶對網絡程序代碼進行修改?

  目前我們已經有1500組針對IE8的設置措施,最主要的就是站點區域分配列表。最 大的難題在於很多公司用戶都有自己的內部網絡“intranet.com”,而瀏覽器對此無法獲知。我們主要關註壹些許可站點,並將用戶分配到這些網絡區 域內,默認使用IE8標準,並在該區域內使用強化的安全設置。用戶需要把自己的內部網絡站點放到該網絡區域內,才能得到認可。這也意味著用戶的首要任務是 盡量增強自己站點的兼容性。

  如何使用虛擬化技術解決嫁接問題?會不會由於需要使用IE6而浪費IE8的優點?

  微軟企業桌面虛擬化技術(MED-V)在這方面為用戶提供了很大的便利。在地址欄內 輸入IE6後,只要不是限定使用IE6的都會自動轉入IE8。用戶的電腦中需要為VM準備足夠的空間,並已經安裝使用MED-V。如果是在XP模式下,用 戶則不能登陸這些網站,同時也最好不用在管理員帳戶登陸狀態下使用IE6訪問不安全頁面。

  公司用戶對於無法移植到IE8中的程序如何處理?甲骨文的Forms 6i和Jinitiator插件如何?

  甲骨文曾表示,他們的系統並非很成功,既然微軟在銷售新系統賺錢,甲骨文也可以如 此。所以長期的策略是對系統進行升級,而短期的對策就是使用虛擬化技術保證相關程序在支持的平臺上運轉正常。我認為沒有人會由此轉用甲骨文,因為平臺並不 支持。當然甲骨文和SAP都有兼容的版本,可是轉為實用甲骨文需要耗資3億美金,歷時1年到1年半,而繼續使用Windows 7系統則明顯省時省力,誰也不想再費勁裝第二個系統。

Hibernate應用中Java對象的狀態

臨時狀態(Transient):也叫瞬時狀態。new出來的對象,沒有被持久化處理,不處於Session緩存中的對象

  持久化狀態(Persistent):已經被持久化,加入到Session的緩存中

  遊離狀態(Detached):也叫脫管狀態。已經被持久化,但是不處在Session緩存中

  ⑴臨時對象的特征:

  不處於Session緩存中(不被任何壹個Session實例關聯)

  在數據庫中沒有對應的記錄

  進入臨時狀態的條件:

  new壹個Java對象,他處於臨時狀態,不和數據庫任何記錄關聯

  Session的delete方法能夠是壹個持久化對象或遊離對象轉變為臨時狀態;對於遊離對象,

  delete方法從數據庫中刪除與它對應的記錄;對於持久化對象,delete方法從數據庫中刪除與它對應的記錄,

  並把它從session緩存中刪除

  ⑵持久化對象的特征:

  在壹個Session實例的緩存中(與壹個Session關聯)

  持久化對象和數據庫中的相關記錄對應

  Session清理緩存時,會根據持久化對象的屬性變化,來同步更新數據庫

  進入持久化狀態的條件

  session的save方法

  session的load和get方法返回的對象都是處於持久化狀態

  session的find方法返回的List中存在的對象都是處於持久化狀態

  session的update、saveOrUpdate和lock方法使得遊離對象轉換為持久化狀態

  當壹個持久化對象關聯壹個臨時對象,在允許級聯保存的情況下,Session在清理緩存時把這個對象也轉變為持久化狀態

  ⑶遊離對象的特征:

  不再位於session緩存中(遊離對象不被Session關聯)

  遊離對象是從持久化對象轉變過來的,因此在數據庫中可能還存在與其對應的記錄

  遊離對象與臨時對象的區別在於:前者是由持久化對象轉變過來的,前者在數據庫中還存在與之對應的記錄,

  而後者在數據庫中沒有與之對應的記錄;

  進入遊離狀態的條件

  當調用session的close方法的時候,session緩存被清空,緩存中的所有持久化對象都變為遊離狀態。如果此時再沒有其它變量引用的時候,其生命周期結束

  session的evict方法能夠從緩存中刪除壹個持久化對象,使它變為遊離狀態。如果內存中存在大量的對象的時候,可以通過這個方法來刪除緩存中的對象(不建議使用這個方法,還是使用查詢的方法和常規方法來處理對象在內存 中的深度)

對Linux內核進行壓力測試

自動軟件測試讓您可以在壹段時間內運行相同的測試,從而確保您所比較的內容具備真正的可比性。在本文中,Linux Test Project 團隊的成員們分享了他們對 Linux? 內核進行壓力所使用的測試的方法、原理以及腳本和工具。

  在對 Linux 內核版本穩定性的測試中,需要明確地聲明並證明為什麽版本是穩定的或者是不穩定的。然而還沒有被證明和證實當前現有的系統範圍內的壓力測試可以測試 Linux 內核整體上的穩定性。本文給出了壹個創建系統範圍內 Linux 壓力測試並證明其結果正確性的方法。不同的 Linux 開發者、用戶和發行版本會使用他們自己的方法來測試內核的穩定性。不過,關於他們決定運行哪些測試、覆蓋的代碼、達到的壓力級別等的基礎信息都沒有發布,這就大大降低了結果的價值。

  使用實驗室的機器以及來自 Linux Test Project 測試套件的測試,我們基於系統資源的利用率統計開發了壹個測試的組合,為系統提供足夠的壓力。我們對這個組合測試進行了分析,以確定 Linux 內核的哪些部分在測試執行中得到了使用。然後,我們修改了組合測試,在保持期望的高強度系統壓力的同時提高代碼覆蓋率的百分比。最終得到的壓力測試涵蓋了 Linux 內核的足夠多部分,有助於穩定性聲明,並且有系統使用情況和內核代碼覆蓋情況的數據來支持它。

  這壹組合測試方法的四個步驟是:測試選擇、系統資源利用率評價、內核代碼覆蓋分析以及最終的壓力測試評價。

  選擇測試

  測試選擇包括選擇達成兩方面目的的測試:

  測試應該可以得到 CPU(s)、內存、I/O 和網絡等主要內核區域的高水平的資源利用率。

  測試應該充分地覆蓋內核代碼,以幫助支持自其結果中生成的穩定性聲明。

  只要有可能,都要使用自動化的或者易於修改的測試,以支持自動操作。自動操作可以使得測試更快而且可以重復進行,並幫助降低人為錯誤的風險。選擇合適的測試時需要考慮的另壹個方面是,使用可以自由發布結果的應用程序。最好是選擇堅決擁護開放源代碼方法和/或 GPL 的測試和測試套件,以助於確保發布過程的簡便。

  評價系統資源利用率

  所選擇的測試的組合必須給系統的資源帶來足夠的壓力。Linux 內核的四個主要方面可以影響系統的響應和執行時間:

  CPU:用於在機器的 CPU(s)上處理數據的時間。

  Memory:用於自真實存儲器中讀寫數據的時間。

  I/O:用於自磁盤存儲器讀寫數據的時間。

  Networking:用於自網絡讀寫數據的時間。

  測試設計者應該使用下面這兩個著名的且廣為應用的開放源代碼 Linux 資源監控工具來評價資源利用率水平。(請參閱本文稍後的 參考資料 以獲得下載這些工具的鏈接。)

  top:由 Albert D. Cahalan 維護著的壹個開放源代碼工具,包含於大部分 Linux 發行版本中,可用於當前的 2.4 和 2.6 內核。

  sar:另壹個開放源代碼工具;它由 Sebastien Godard 維護。這個工具也包含於大部分 Linux 發行版本中,可用於當前的 2.4 和 2.6 內核。

  方法中的系統資源利用率評價階段通常需要多次嘗試才能得到合適的測試組合,並得到期望水平的利用率。當確定測試組合時,過度利用總是壹個至關重要的問題。例如,如果選擇的組合過於受 I/O 所限,可能會導致 CPU 的測試結果不好,反之亦然。方法的這壹部分主要是大量的試驗和出錯,直到所有資源達到期望水平。

  top 工具可用於迅速確定每個測試影響哪個資源(CPU、內存或者 I/O),並實時地顯示出它們使用了多少資源。 sar 工具用於收集壹段時間內的網絡利用率統計數據,並將所有利用率數據的快照記錄到壹個文件。

  當選定壹個組合後,測試必須長時間運行以準確評價資源的利用率。測試運行的時間長短取決於每個測試的長度。假如多個測試同時運行,則時間必須足夠長以使得這些測試中最長的那個可以完成。在這個評價過程中,sar 工具也應該在運行。在評價運行的結論中,您應該收集並評價所有四種資源的利用率水平。