This blog will not introduce how an ICF handler class in ABAP or a Servlet in Java are developed, but focus the way those instances of handler class or Servlet are spawned by Web Server. Let’s first study the Servlet spawn behavior in Java. Servlet in Java According to Servlet specification, http request against a given url will be served by the same single instance of servlet. For example, I have developed a simple Servlet which just returns “Hello world” as response. I map it with url starting with “/Hello”. In the doGet method, I print out the current thread id and instance address to try to verify if every request is served with the SAME servlet instance. System.out.println("User id: " + userId + " at thread: " + Thread.currentThread().getId() + " current instance: " + this); In client side I use jQuery to send out five different request simultaneously: var LOCAL = "http://localhost:9098/JerryServlet/Hello?userId="; var PREFIX = "i04241"; function main() { for( var i = 0; i < 5; i++) { var url = LOCAL + PREFIX + i; var html = getPostByAJAX(url); console.log("response: " + html); } } $(function(){ main(); }); function getPostByAJAX(requestURL){ var html = $.ajax({ url: requestURL, async: true}).responseText; return html; } When executing the client JavaScript code, I observe in Server console and could find out that these five requests are handled by the same Servlet instance ,however in different threads. Since I perform the request in an asynchronous mode, so the response of those five requests are processed and returned in parallel. How singleton behavior of Servlet is achieved The instance of requested Servlet will only be initialized when it is asked for the first time. The below two-fold instance checking against null is a typical thread-safe implementation pattern for Singleton in Java. The method loadServlet in class StandardWrapper will call constructor of my sample Servlet via reflection. All subsequent request will be served by this singleton. Thread pool in Java Servlet This thread pool behavior is easy to observe, just set breakpoint in doGet method in my Servlet, line 58: Perform the client code to send five requests, then in Eclipse we can see the five working threads stopped at the breakpoint at the same time: From the bottom of callstack we get the hint that those working threads are centrally managed by the Thread pool. ICF Handler class in ABAP Create a simple ICF service in tcode SICF and implement its handler class. Set a breakpoint on method HANDLE_REQUEST, then trigger the request sending in client code: Five debugger windows will pop up for the same time, each for one separate ABAP session where the request is handled. From this source code we know the fact that in ABAP, the instance of handler class does not behave as singleton in Java Servlet. From debugging we can observe that different session has different ICF handler instance which are isolated among each other.