Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
If you write Web applications in Java, the servlet is your best friend. Whether you write Java ServerPages (JSP) or plain servlets, you are both at the servlet's mercy and the lucky recipient of what the servlet has to offer. So let's look closer at the servlet.
As we know, when building a Website, we are primarily interested in the servlet's two methods:
doGet(). The underlining method for both methods is
service(). Later, I look closer at these methods and how they relate to thread safety, but first let's review the concept of a thread.
A thread is a single execution process; in other words, an individual, sequential flow of control within a program. When we say that a program is multithreaded, we are not implying that the program runs two separate instances simultaneously (as if you concurrently executed the program twice from the command line). Rather, we are saying that the same instance (executed only once) spawns multiple threads that process this single instance of code. This means that more than one sequential flow of control runs through the same memory block.
So what do we mean by thread-safe, you ask? When multiple threads execute a single instance of a program and therefore share memory, multiple threads could possibly be attempting to read and write to the same place in memory. Let's look at an example. If we have a multithreaded program, we will have multiple threads processing the same instance (see Figure 1).
Figure 1. A multithreaded application
What happens when
Thread-A examines variable
instanceVar? Notice how
Thread-B has just incremented
instanceVar. The problem here is
Thread-A has written to the
instanceVar and is not expecting that value to change unless
Thread-A explicitly does so. Unfortunately
Thread-B is thinking the same thing regarding itself; the only problem is they share the same variable. This issue is not unique to
servlets. It is a common programming problem only present when multithreading an application. You are probably thinking; "Well
I didn't ask for multithreading. I just want a servlet!" And a servlet is what you have. Let me introduce you to our friend
the servlet container.
A lot of magic happens between the Web browser's HTTP request and the code we write within the
doPost() methods. The servlet container makes this "magic" possible. Like any Java program, the servlet must run within a JVM, but
for a Web application, we also have the complexity of handling HTTP requests—that's where the servlet container comes in.
The servlet container is responsible for your servlets' creation, destruction, and execution; the sequence of these events
is referred to as the servlet's lifecycle.
The servlet's lifecycle is an important topic, and thus, you will find it on Sun's Java certification exam. The reason for its importance is primarily because so much of the servlet's lifecycle is outside the programmer's control. We do not worry a lot (for the most part) about how many of our servlet's instances exist at runtime. Nor are we generally concerned about memory utilization regarding the creation and destruction of our servlets. The reason for our lack of concern is because the servlet container handles this for us (yes, more magic).
|Forum migration complete By Athen|
|Forum migration update By Athen|
|The synchronized block is NOT small By Anonymous|
Write thread-safe servlets By JavaWorld
( 1 2 all )
|Good article By Alpha|
|Warning about the Mutex Object By Goonie|