<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    鷹翔宇空

    學習和生活

    BlogJava 首頁 新隨筆 聯(lián)系 聚合 管理
      110 Posts :: 141 Stories :: 315 Comments :: 1 Trackbacks
    原文摘自:http://forum.javaeye.com/viewtopic.php?t=17501&postdays=0&postorder=asc&start=0

    文章時間: 2005-12-11 12:15:26    標題: 引用回復 將這個帖子加入我的Blog

    hongliang 寫道:
    那這么說來,假設Hibernate在第一秒拿到叻數(shù)據(jù)庫連接,這個連接不還是持續(xù)15秒么?


    如果是網(wǎng)絡傳輸速度導致load頁面需要15秒,那么時間消耗在網(wǎng)絡傳輸上,本身頁面執(zhí)行時間很短。

    如果不是網(wǎng)絡傳輸速度導致load頁面需要15秒,那說明什么?說明這個頁面的程序執(zhí)行了15秒!為什么一個頁面程序需要執(zhí)行這么久呢?說明這個頁面的數(shù)據(jù)庫查詢非常耗時!(純內(nèi)存操作都是ms級別的,如果都10多秒了,瓶頸只可能是數(shù)據(jù)庫操作) 如果數(shù)據(jù)庫查詢需要15秒,請問你就算不用OpenSessionInView,你不是一樣需要打開數(shù)據(jù)庫連接長達15秒嗎?
    文章時間: 2005-12-11 12:32:42    標題: 引用回復 將這個帖子加入我的Blog

    我明白robbin你的意思,我說的情況就是網(wǎng)絡傳輸導致的15秒。本身頁面執(zhí)行的時間,比如freemarker渲染一下模板,這個速度是非常快的,沒問題,可是我的疑問就在于如果網(wǎng)絡傳輸狠慢,會不會影響到數(shù)據(jù)庫連接。

    假設WebWork+Hibernate+FreeMarker架構模型是這樣的

    Request
    |
    |---other filters...
    |
    |---OpenSessionInView Filter
    |
    |-----WebWork Controller
    |
    |---Action
    |
    |---FreeMarker Result(對response.getWriter()做process()操作)
    |
    |
    |---OpenSessionInView Filter
    |
    |---other filters...
    |
    Request


    這里有兩種情況。

    一是頁面緩沖區(qū)足夠大,足夠一次性容納所有的頁面,這樣渲染頁面就會一次性進入緩沖區(qū),然后返回到OpenSessionInView Filter,關閉Session,數(shù)據(jù)庫連接返回池中,一切OK。

    第二種情況我是重點想討論的,也是我的疑慮所在。那就是假如這個頁面比較大,超出叻頁面緩沖區(qū)的大小,那么渲染頁面時,就拿FreeMarker/Velocity這樣的模板語言來說,它執(zhí)行process/merge方法,往servlet的response writer/outputStream里面寫東西,寫著寫著,發(fā)現(xiàn)寫不動叻,是緩沖區(qū)滿叻,而這個writer/outputStream,正是服務器同用戶之間建立的socket請求,于是底層代碼開始先向用戶傳輸一部分頁面,傳好后,又有叻新的緩沖區(qū),F(xiàn)reeMarker/Velocity的方法又能向緩沖區(qū)里寫東西叻。而傳輸頁面這個過程,又耗費叻幾秒鐘的時間,就導致叻數(shù)據(jù)庫連接被占用叻狠長的時間。

    可能我描述的是錯誤的,希望robbin指正!:)
    文章時間: 2005-12-11 13:07:27    標題: 引用回復 將這個帖子加入我的Blog

    我覺得這個問題歸根結底就是AppServer究竟會如何實現(xiàn)頁面輸出。那么必然和具體的應用服務器實現(xiàn)有關系。那么至于每個AppServer究竟會怎樣去實現(xiàn),我就不得而知了。起碼大家可以研究一下Tomcat源代碼看看tomcat是如何實現(xiàn)的。

    confluence采用的就是Hibernate/Spring/Webwork架構,OpenSessionInView,以confluence這么廣的使用,好像也沒有聽過這方面的問題投訴。
    文章時間: 2005-12-11 18:26:22    標題: 引用回復 將這個帖子加入我的Blog

    我寫了一個簡單的webapp在Tomcat5.5.12上面做了一個小測試。在JSP頁面里面循環(huán)1萬次輸出字符串,程序在遠程服務器上面運行,網(wǎng)絡是ADSL寬帶,filter確實被阻塞了20秒左右。然后我另外開了一個flashget去下載服務器上的大文件,模擬網(wǎng)絡速度比較慢的環(huán)境,filter被阻塞了50秒左右。分別做了三次測試。另外當頁面下載過程中直接點擊瀏覽器stop按鈕,則JSP執(zhí)行被打斷,filter立刻解除阻塞,被執(zhí)行完畢。

    結論證明,使用OpenSessionInView的時候,如果render的頁面數(shù)據(jù)量非常大,并且客戶端網(wǎng)絡速度很慢的情況下,由于頁面的輸出時間過程很長,確實會造成filter被長時間阻塞。對于OpenSessionInViewFilter來說,就會造成數(shù)據(jù)庫連接被保持很長的時間,才能被關閉。

    不過,對于Spring的OpenSessionInViewFilter來說,雖然數(shù)據(jù)庫連接被保持了過長的時間,但是并沒有鎖定數(shù)據(jù)庫資源,特別是事務資源。因為Spring的事務是通過TransactionInterceptor來實現(xiàn)的,在MVC結構中,當最后一個業(yè)務bean被調(diào)用結束以后,Transaction就已經(jīng)被提交了。此后,雖然數(shù)據(jù)庫連接還保持中,但是數(shù)據(jù)庫資源沒有鎖定問題。

    完整的調(diào)用示意圖:

    request -> (OpenSessionInViewFilter打開Session) -> ServletDispatcher -> Action -> (打開Connection,啟動事務) -> spring bean -> another spring bean -> (提交事務) -> bean執(zhí)行完畢,返回Action -> render view(JSP/Template) -> (OpenSessionInViewFilter關閉Session和Connection)
    文章時間: 2005-12-11 22:44:45    標題: 引用回復 將這個帖子加入我的Blog

    robbin的分析很透徹,對于最后一點,我稍有疑問。

    引用:

    對于Spring的OpenSessionInViewFilter來說,雖然數(shù)據(jù)庫連接被保持了過長的時間,但是并沒有鎖定數(shù)據(jù)庫資源,特別是事務資源。


    其實我認為數(shù)據(jù)庫連接被保持過長時間有時候會有很大的問題。尤其是對于采用數(shù)據(jù)連接池的情況,如果你的數(shù)據(jù)庫連接一直被保持,那么這個資源就未被釋放。假設說這個數(shù)據(jù)連接池的最大連接數(shù)為15,我感覺很容易造成數(shù)據(jù)庫的連接不夠用。

    不清楚底層的實現(xiàn)是如何做的,或許我的疑問有些多慮。
    文章時間: 2005-12-11 22:51:56    標題: 引用回復 將這個帖子加入我的Blog

    downpour 寫道:
    robbin的分析很透徹,對于最后一點,我稍有疑問。

    引用:

    對于Spring的OpenSessionInViewFilter來說,雖然數(shù)據(jù)庫連接被保持了過長的時間,但是并沒有鎖定數(shù)據(jù)庫資源,特別是事務資源。


    其實我認為數(shù)據(jù)庫連接被保持過長時間有時候會有很大的問題。尤其是對于采用數(shù)據(jù)連接池的情況,如果你的數(shù)據(jù)庫連接一直被保持,那么這個資源就未被釋放。假設說這個數(shù)據(jù)連接池的最大連接數(shù)為15,我感覺很容易造成數(shù)據(jù)庫的連接不夠用。

    不清楚底層的實現(xiàn)是如何做的,或許我的疑問有些多慮。


    按道理來說,數(shù)據(jù)庫連接應該盡早被釋放,以緩解數(shù)據(jù)庫資源的壓力,延遲很久才釋放,確實會導致需要更多的數(shù)據(jù)庫連接。這個就只能擴大連接池數(shù)量,增加數(shù)據(jù)庫最大允許連接數(shù)來解決了。

    此外,Session被延遲很久釋放,那么Session占用的一級緩存也會占用比較長時間,這意味著會無謂消耗更多的JVM內(nèi)存。

    因此,OpenSessionInView雖然確實方便,但是大家還是慎用吧。對于那些頁面渲染速度很慢,撥號連接用戶數(shù)量過多的網(wǎng)站就最好不要使用。
    文章時間: 2005-12-14 10:22:24    標題: 引用回復 將這個帖子加入我的Blog

    引用:
    因此,OpenSessionInView雖然確實方便,但是大家還是慎用吧。對于那些頁面渲染速度很慢,撥號連接用戶數(shù)量過多的網(wǎng)站就最好不要使用。

    確切的應該是大并發(fā)用戶量的情況吧。這個問題一直都存在,在1年多前我和robbin爭論中就提出來了過。hibernate2的代碼可以看到session是和connection緊密耦合的(Hibernate3沒看過)。但hibernate大部分被用于并發(fā)用戶可預見的intranet應用,所以問題也不是很大。如果并發(fā)用戶多,對connection pool資源, opensession in view在hibernate中使用會構成較大壓力。如果jboss j2ee5 server采用hibernate作為ejb3實現(xiàn),沒有做修正的話,同樣的問題也會存在于jboss j2ee5 server中。


    上一次由Charlesxp于2005-12-14 周三, 上午10:25修改,總共修改了2次
    文章時間: 2005-12-14 10:22:33    標題: 引用回復 將這個帖子加入我的Blog

    hongliang 寫道:
    幾天沒來,居然變精華叻。。。本來我也想做一下robbin的那個測試,結果這幾天忙于其它事,一直沒時間。看來OpenSessionInView果然有這個問題,這也是我一直擔心的,看來真是應叻那句話,“如果一件事可能出錯,那它一定會出錯”。。。

    不過,如果不用OpenSessionInView,我還真一下子就找不到北叻,從學Hibernate開始就一直在OpenSessionInView的熏陶下長大。。。-_-b

    Robbin有什么好的辦法能夠在不使用OpenSessionInView的情況下比較好的處理頁面嗎?


    在dao中對要render的集合強制初始化。
    文章時間: 2005-12-14 10:51:52    標題: 引用回復 將這個帖子加入我的Blog

    hongliang 寫道:
    是不是像這樣?

    foo.getBars()


    Hibernate.initialize(foo.getBars);
    posted on 2006-02-10 09:52 TrampEagle 閱讀(1492) 評論(0)  編輯  收藏 所屬分類: hibernateSpring
    主站蜘蛛池模板: 中文字幕免费在线看| 一二三区免费视频| 免费观看黄色的网站| 亚洲av成人无码久久精品| 成全在线观看免费观看大全| 国产亚洲精品资在线| 黄床大片免费30分钟国产精品 | 67194在线午夜亚洲| 亚洲免费一级视频| 久久亚洲国产精品成人AV秋霞| 香蕉免费一区二区三区| 久久精品国产亚洲AV大全| 中文字幕免费在线看线人| 亚洲H在线播放在线观看H| 午夜老司机免费视频| 国产精品久久亚洲一区二区| 亚洲精品国产综合久久一线| free哆拍拍免费永久视频| 91麻豆精品国产自产在线观看亚洲| 热久久这里是精品6免费观看| 亚洲Av综合色区无码专区桃色| 久久国产精品一区免费下载| 亚洲精品欧洲精品| 成年女人午夜毛片免费看| 深夜a级毛片免费视频| 中文字幕人成人乱码亚洲电影 | 最近2019免费中文字幕视频三| 亚洲一区二区三区在线观看蜜桃| 4hu四虎最新免费地址| 日韩欧美亚洲中文乱码| 在线亚洲97se亚洲综合在线| 亚洲成人免费在线| 国产亚洲精品影视在线| 亚洲中文无韩国r级电影| 91人人区免费区人人| 亚洲国产成人久久精品软件| 亚洲欧洲日产国码av系列天堂| 18pao国产成视频永久免费| 亚洲av成人片在线观看| 亚洲AV综合色区无码一区爱AV| 女性自慰aⅴ片高清免费|