Servlet3規范支持異步請求（或者稱為長連接，或者反向AJAX，或者COMET，或者服務器推送技術）：無阻塞的輸入與輸出模型，可以延時的請求和響應功能，還有超時事件通知，看上去一切都是那么完美。
但終端瀏覽器支持長連接情況差強人意，對Comet的支持大致匯總如下：
- IE瀏覽器最佳實踐是使用htmlfile ActiveXObject，以及創建隱藏IFrame組件，可以跨越IE6-IE8;雖IE 8支持XDomainRequest支持HTTP Streaming，但僅僅是IE 8。
- Firefox 瀏覽器相當棒，支持XMLHttpRequest Streaming 和隱藏的IFrame組件。
- Safari 瀏覽器支持XMLHttpRequest Streaming。
- Chrome有些無奈，算不上支持XMLHttpRequest Streaming，使用IFrame的話會一直出現正在加載中的標志。
- Opera也不支持XMLHttpRequest Streaming，使用IFrame的話會一直出現正在加載中的標志。
總之，使用IFrame是一個不錯的方案，在IE、Firefox下表現的很完美，在其它瀏覽器下只能忍受討厭的正在加載中。數據交換格式可以采用JS腳本調用。
但無論哪一種方案，都必須認識到，一個持久的連接，當頁面內容一直在遞增時，會越來越膨脹，會占用用戶機器的CPU，盡量隔一段時間斷開連接，重新請求。
HTTP 1.1規范中聲明客戶端不應該與服務器端建立超過兩個 HTTP 連接,因此瀏覽器內需要借助腳本避免客戶重開兩個腳本。
按照目前情形下，需要借助AJAX PULL + COMET PUSH 相結合來打造相當好的用戶體驗。
Servlet本身，無論2.4或者2.5的版本，可以使用一個循環達到長連接的目標：
/**
* 一個典型的長連接實現
*
* @author yongboy
* @date 2011-1-14
* @version 1.0
*/
@WebServlet("/demoLongLink")
public class DemoLongLinkServlet extends HttpServlet {
private static final long serialVersionUID = 4617227991063927036L;
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
response.setHeader("Cache-Control", "private");
response.setHeader("Pragma", "no-cache");
response.setHeader("Connection", "Keep-Alive");
response.setHeader("Proxy-Connection", "Keep-Alive");
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
out.println("<div>Start ...</div>");
out.flush();
int num = 0;
int max = 100;
while (true) {
out.println("<div>" + (num++) + "</div>");
out.flush();
if (num >= max) {
break;
}
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
out.println("<div>Done !</div>");
out.flush();
out.close();
}
}
每一個連接線程都處于一個不斷循環之中，不能夠有效釋放，相當的浪費服務器資源，有可能導致容器內線程池耗盡，將無法應對后續請求。同時少了異步連接的特性，無法直接定義超時時間，更不要說超時事件，超時監聽器等企業特性了。
當然也可以實現異步請求，但可能沒有規范那般嚴格。
同步請求的模型：
對比異步請求模型：
在前兩篇文章中，使用一個單獨線程處理資源，分發到大部分的異步請求中。