Java Servlet Tutorial - Part 1, September 2002
I've been asked by several people to do some "lite" tutorials on servlets and JSP's so I'm going to cover as much as I can over the next several months without writing a book! I can't cover every detail but since many of my students are just getting into server side Java I'll try to cover the most important topics & concepts involving servlets. I also have to assume that if you're reading this you have some basic knowledge of the Java language!
The Basic Http Server Request - Response Model
Before we even start discussing servlets you have to understand how a typical browser / server interaction happens. When a user opens a browser and types a
URL into the
location bar, or clicks on a link, a Request is made of the server that the site resides on, simply put you are requesting the page be downloaded to your machine. The server searches the
directory you've specified, locates the appropriate page and returns it to you in a Response. When a form is submitted to a server the request contains all of the information that was
entered into the form. Similarly using a URI attached to a URL sends specific
information along with the request. What's a URI you say? Look at the location bar in the browser right now.
You will notice a ? in the link. That question mark is a separator that servers understand. Everything after the ? is information the page needs to load properly and is called a URI. This is
commonly know as a GET method for forms but can also be used on links to add data to a request of the server. This information is sent using name-value pairs, as with this page (look at
your location bar again) the link to get this page has sent a parameter name called pageName with a value of javaServlets.
So what have we got here so far? OK my browser asks the server for a given page with or without additional information attached to the page request and the server basically says
Here's what you asked for
. In it's simplest form that's exactly how it works.
Servlet Object Basics
One huge source of confusion for beginning servlet programmers is how & where these objects reside. I have seen people who thought the objects are passed back &
forth from the browser & the server....absolutely NOT! All objects reside on the server inside a container (IE: the servlet "engine"). These objects will "live" until they are no longer
required and will then be garbage collected when the JVM feels it needs memory. So just like when a program is
loaded into memory on your home computer, the JVM loads the
servlet into the memory of the server. One major difference is that a servlet instance is only loaded once into memory, not once for every user that makes a request to that servlet! So how
do all these users get their own page. Every time another user makes a request for a servlet a new thread is created for them. This is an important concept that you MUST be aware of
when building servlets. Because all your users are sharing the same instance of your servlets, just in separate threads, they are NOT Thread safe! You will find information out there that
states Anything inside a doPost or a doGet is thread safe
but I have had problems in these methods so if it's critical information be careful!
So what's this mean to you? Well, first of all class variables are VERY dangerous in servlets if they are meant to hold different values for each user. Static variables, as well as
methods, can also be very dangerous.......you must remember all of your users are using the same one! Last but not least you must watch sensitive methods that are relying on
things to happen for one user at a time. Remember you may have thousands (possibly millions) of users in a given servlet just milliseconds apart from each other at any given time.
So how do you combat all this? First make all of your variables, as local as humanly possible. Pass variables around in your method calls. Also keep your access modifiers as tight
as you can! Synchronize methods that have to be accessed by only one user at a time but do this sparingly....you can build up one heck of a waiting list
if your methods are large and
are synchronized. I prefer to use synchronized blocks for this type of work. Lastly, if you are really having a problem you can have your servlet implement the SingleThreadModel. This
interface has no methods whatsoever but ensures your servlet will handle only one user request at a time. If at all possible try not to use this because it can slow your servlet down to
a crawl but on extremely sensitive information servlets this may be your only choice. So with all this said let's build a servlet and explore some of the finer points of server side Java!
Theresa Judd, permanentcosmeticsbytheresa.com | More Testimonials >>