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

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

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

    Sealyu

    --- 博客已遷移至: http://www.sealyu.com/blog

      BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
      618 隨筆 :: 87 文章 :: 225 評論 :: 0 Trackbacks

    A general discussion of concurrent calls to Seam components can be found in Section 4.1.10, “Concurrency model”. Here we will discuss the most common situation in which you will encounter concurrency — accessing conversational components from AJAX requests. We're going to discuss the options that a Ajax client library should provide to control events originating at the client — and we'll look at the options RichFaces gives you.

    Conversational components don't allow real concurrent access therefore Seam queues each request to process them serially. This allows each request to be executed in a deterministic fashion. However, a simple queue isn't that great — firstly, if a method is, for some reason, taking a very long time to complete, running it over and over again whenever the client generates a request is bad idea (potential for Denial of Service attacks), and, secondly, AJAX is often to used to provide a quick status update to the user, so continuing to run the action after a long time isn't useful.

    Therefore, when you are working inside a long running conversation, Seam queues the action event for a period of time (the concurrent request timeout); if it can't process the event in time, it creates a temporary conversation and prints out a message to the user to let them know what's going on. It's therefore very important not to flood the server with AJAX events!

    We can set a sensible default for the concurrent request timeout (in ms) in components.xml:


    <core:manager concurrent-request-timeout="500" />

    We can also fine tune the concurrent request timeout on a page-by-page basis:


    <page view-id="/book.xhtml" 

             conversation-required="true" 

             login-required="true"

             concurrent-request-timeout="2000" />

    So far we've discussed AJAX requests which appear serial to the user - the client tells the server that an event has occur, and then rerenders part of the page based on the result. This approach is great when the AJAX request is lightweight (the methods called are simple e.g. calculating the sum of a column of numbers). But what if we need to do a complex computation thats going to take a minute?

    For heavy computation we should use a poll based approach — the client sends an AJAX request to the server, which causes action to be executed asynchronously on the server (the response to the client is immediate) and the client then polls the server for updates. This is good approach when you have a long-running action for which it is important that every action executes (you don't want some to timeout).

    Well first, you need to decide whether you want to use the simpler "serial" request or whether you want to use a polling approach.

    If you go for a "serial" requests, then you need to estimate how long your request will take to complete - is it much shorter than the concurrent request timeout? If not, you probably want to alter the concurrent request timeout for this page (as discussed above). You probably want a queue on the client side to prevent flooding the server with requests. If the event occurs often (e.g. a keypress, onblur of input fields) and immediate update of the client is not a priority you should set a request delay on the client side. When working out your request delay, factor in that the event may also be queued on the server side.

    Finally, the client library may provide an option to abort unfinished duplicate requests in favor of the most recent.

    Using a poll-style design requires less fine-tuning. You just mark your action method @Asynchronous and decide on a polling interval:


    }

    However carefully you design your application to queue concurrent requests to your conversational component, there is a risk that the server will become overloaded and be unable to process all the requests before the request will have to wait longer than the concurrent-request-timeout. In this case Seam will throw a ConcurrentRequestTimeoutException which can be handled in pages.xml. We recommend sending an HTTP 503 error:


       <exception class="org.jboss.seam.ConcurrentRequestTimeoutException" logLevel="trace">

          <http-error error-code="503" />

       </exception>

    Alternatively you could redirect to an error page:


    <exception class="org.jboss.seam.ConcurrentRequestTimeoutException" logLevel="trace">

       <end-conversation/>

       <redirect view-id="/error.xhtml">

          <message>The server is too busy to process your request, please try again later</message>

       </redirect>

    </exception>

    ICEfaces, RichFaces Ajax and Seam Remoting can all handle HTTP error codes. Seam Remoting will pop up a dialog box showing the HTTP error and ICEfaces will indicate the error in it's connection status component. RichFaces Ajax provides the most complete support for handling HTTP errors by providing a user definable callback. For example, to show the error message to the user:

    <script type="text/javascript">
    A4J.AJAX.onError = function(req,status,message) {
    alert("message");
    };
    </script>

    RichFaces Ajax is the AJAX library most commonly used with Seam, and provides all the controls discussed above:

    posted on 2009-07-20 10:17 seal 閱讀(755) 評論(0)  編輯  收藏 所屬分類: Seam
    主站蜘蛛池模板: 免费在线观看一级片| 免费视频成人国产精品网站| 曰批全过程免费视频在线观看无码| 亚洲黄片毛片在线观看| 色www免费视频| 亚洲精品一级无码鲁丝片| 亚洲av无码av在线播放| 大陆一级毛片免费视频观看 | 亚洲最大激情中文字幕| 国产精品福利在线观看免费不卡| 亚洲欧洲中文日韩久久AV乱码| www永久免费视频| 亚洲AV无码精品色午夜在线观看| 国产精品免费AV片在线观看| 久久久亚洲欧洲日产国码aⅴ| 精品国产污污免费网站aⅴ| 在线观看亚洲AV每日更新无码| 日本黄色免费观看| 国产精品免费αv视频| 久久精品国产精品亚洲艾草网| 4虎1515hh永久免费| 亚洲日本一线产区和二线 | 免费观看理论片毛片| 免费一级特黄特色大片| 亚洲五月综合缴情在线观看| 95免费观看体验区视频| 国产精品亚洲精品| 亚洲国产精品一区二区第四页| 日本高清免费观看| 亚洲乱码日产精品一二三| 国产偷国产偷亚洲清高动态图| 在线看无码的免费网站| 亚洲国产综合AV在线观看| 国产成人精品久久亚洲| 在线观看免费中文视频| 激情小说亚洲图片| 亚洲AV日韩AV永久无码免下载 | 亚洲av手机在线观看| 久久午夜无码免费| 国产亚洲精品美女久久久久| 亚洲精品乱码久久久久66|