Es stellte sich heraus das, mit der neuen Servlet 3.0 Spezifikation, Servlets einen AJAX Support aufweisen. Doch was bedeutet dies genau? Ein wirklich sehr guter Artikel auf JavaWorld.combrachte mir die Erkenntnis.

Jedes mal wenn ein Client einen Request an einen Webserver stellt, und das kann in der heutigen AJAX Zeit sehr oft der Fall sein, wird ein neuer Server Thread diesem Client Request zugeteilt. Je nach Implementierungslogik kann es sehr lange dauern bis dieser Request beantwortet wird, z.B. weil zuerst eine JDBC Verbindung aufgebaut werden muss, etc. Solange der Request nicht gegen einen Timeout läuft verbleibt dieser mit all seinen belegten Ressourcen offen. Diesem UseCase kann man natürlich entgegenwirken, indem z.B. AJAX Polling Mechanismen immer wieder nach dem Status fragen, Servlets neue Threads erzeugen, die die Verarbeitung des Client Requests abarbeiten, und dem Client über einen Status mitteilen ob ihr Ergebnis fertig ist oder nicht.

Der Servlet 3.0 Ansatz verfolgt eine etwas andere Strategie, indem er den Client aktiv benachrichtigt (PUSH). Quellcode sagt hier vielleicht mehr als tausen Worte, deswegen ein kurzes Beispiel.

@WebServlet(name="myServlet", urlPatterns={"/auctionservice"}, asyncSupported=true)
public class MyServlet extends HttpServlet {

   // track bid prices
   public void doGet(HttpServletRequest request, HttpServletResponse response) {
      AsyncContext aCtx = request.startAsync(request, response);
      // This could be a cluser-wide cache.
      ServletContext appScope = request.getServletContext();
      Map> aucWatchers = (Map>)appScope.getAttribute("aucWatchers");
      List watchers = (List)aucWatchers.get(request.getParameter("auctionId"));
      watchers.add(aCtx); // register a watcher
   }

   // place a bid
   public void doPost(HttpServletRequest request, HttpServletResponse response) {
      // run in a transactional context
      // save a new bid
      AsyncContext aCtx = request.startAsync(request, response);
      ServletContext appScope = request.getServletContext();
      Queue aucBids = (Queue)appScope.getAttribute("aucBids");
      aucBids.add((Bid)request.getAttribute("bid"));  // a new bid event is placed queued.
   }
}

@WebServletContextListener
public class BidPushService implements ServletContextListener{

   public void contextInitialized(ServletContextEvent sce) {
      Map> aucWatchers = new HashMap>();
      sce.getServletContext().setAttribute("aucWatchers", aucWatchers);
      // store new bids not published yet
      Queue aucBids = new ConcurrentLinkedQueue();
      sce.getServletContext().setAttribute("aucBids", aucBids);

      Executor bidExecutor = Executors.newCachedThreadPool();
      final Executor watcherExecutor = Executors.newCachedThreadPool();
      while(true)
      {
         if(!aucBids.isEmpty()) // There are unpublished new bid events.
         {
            final Bid bid = aucBids.poll();
            bidExecutor.execute(new Runnable(){
               public void run() {
                  List watchers = aucWatchers.get(bid.getAuctionId());
                  for(final AsyncContext aCtx : watchers)
                  {
                     watcherExecutor.execute(new Runnable(){
                        public void run() {
                           // publish a new bid event to a watcher
                           aCtx.getResponse().getWriter().print("A new bid on the item was placed. The current price ..., next bid price is ...");
                        };
                     });
                  }
               }
            });
         }
      }
   }

   public void contextDestroyed(ServletContextEvent sce) {
   }
}

Wie man sieht werden die beiden üblichen Methoden, doGet und doPost, des Servlets sehr schnell abgearbeitet, indem ein sog. AsyncContext erzeugt wird. Über diesen Context hat man dann die Möglichkeit den Client asynchron eine Antwort zu schicken (PUSH). In meinen Augen eine sehr elegante Implementierungsmöglichkeit.

Bleibt allerdings nur noch eine Frage offen. Was ist im Endeffekt schlimmer? Ein ständiger kurzer Polling Mechanismus durch den Client oder eine Pushvariante nach dem Streaming oder Long Polling Mechanismus. Nun, letztendlich bleibt einem nichts weiter übrig als die Serlvet 3.0 Spezifikation abzuwarten und das Ergebnis selbst einmal auszuprobieren.