Just another weblog

  • Subscribe

  • Recent Posts

  • Pages

  • Archives

  • Top Clicks

    • None
  • Advertisements

Servlets Interview Questions

Posted by damuchinni on February 16, 2009

1) Is it the “servlets” directory or the “servlet” directory?

For Java Web Server:

* on the file system, it’s “servlets”

* in a URL path, it’s “servlet”

2) How do I support both GET and POST protocol from the same Servlet?

The easy way is, just support POST, then have your doGet method call your doPost method:

public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException
doPost(req, res);

3) How do I ensure that my servlet is thread-safe?

This is actually a very complex issue. A few guidelines:

1. The init() method is guaranteed to be called once per servlet instance, when the servlet is loaded. You don’t have to worry about thread safety inside this method, since it is only called by a single thread, and the web server will wait until that thread exits before sending any more threads into your service() method.
2. Every new client request generates (or allocates) a new thread; that thread calls the service() method of your servlet (which may in turn call doPost(), doGet() and so forth).
3. Under most circumstances, there is only one instance of your servlet, no matter how many client requests are in process. That means that at any given moment, there may be many threads running inside the service() method of your solo instance, all sharing the same instance data and potentially stepping on each other’s toes. This means that you should be careful to synchronize access to shared data (instance variables) using the synchronized keyword.
4. (Note that the server will also allocate a new instance if you register the servlet with a new name and, e.g., new init parameters.) Note that you need not (and should not) synchronize on local data or parameters. And especially you shouldn’t synchronize the service() method! (Or doPost(), doGet() et al.)
5. A simple solution to synchronizing is to always synchronize on the servlet instance itself using "synchronized (this) { … }". However, this can lead to performance bottlenecks; you’re usually better off synchronizing on the data objects themselves.
6. If you absolutely can’t deal with synchronizing, you can declare that your servlet "implements SingleThreadModel". This empty interface tells the web server to only send one client request at a time into your servlet. From the JavaDoc: "If the target servlet is flagged with this interface, the servlet programmer is guaranteed that no two threads will execute concurrently the service method of that servlet. This guarantee is ensured by maintaining a pool of servlet instances for each such servlet, and dispatching each service call to a free servlet. In essence, if the servlet implements this interface, the servlet will be thread safe." Note that this is not an ideal solution, since performance may suffer (depending on the size of the instance pool), plus it’s more difficult to share data across instances than within a single instance.

See also What’s a better approach for enabling thread-safe servlets and JSPs? SingleThreadModel Interface or Synchronization?
7. To share data across successive or concurrent requests, you can use either instance variables or class-static variables, or use Session Tracking.
8. The destroy() method is not necessarily as clean as the init() method. The server calls destroy either after all service calls have been completed, or after a certain number of seconds have passed, whichever comes first. This means that other threads might be running service requests at the same time as your destroy() method is called! So be sure to synchronize, and/or wait for the other requests to quit. Sun’s Servlet Tutorial has an example of how to do this with reference counting.
9. destroy() can not throw an exception, so if something bad happens, call log() with a helpful message (like the exception). See the "closing a JDBC connection" example in Sun’s Tutorial.

4) What is the difference between URL encoding, URL rewriting, HTML escaping, and entity encoding?

URL Encoding is a process of transforming user input to a CGI form so it is fit for travel across the network — basically, stripping spaces and punctuation and replacing with escape characters. URL Decoding is the reverse process. To perform these operations, call and (the latter was (finally!) added to JDK 1.2, aka Java 2).

Example: changing “We’re #1!” into “We%27re+%231%21”

URL Rewriting is a technique for saving state information on the user’s browser between page hits. It’s sort of like cookies, only the information gets stored inside the URL, as an additional parameter. The HttpSession API, which is part of the Servlet API, sometimes uses URL Rewriting when cookies are unavailable.

Example: changing

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: