Chapter 11: Class Loading and Synchronization

---

Overview

We've learnt a lot about the power of servlets and how we can use them in web applications, but when we were testing all of these things, we did so on a single computer, with no more than a few users accessing the web application at a time. This is not the situation we would find our web applications and servlets dealing with in a production environment - then they would be expected to deal with thousands of simultaneous connections. There are many considerations we must make for a production system that can be easily overlooked when we are developing and testing applications in an environment that we control.

In an environment that we don't control, changes might be made to the system that adversely affect our application. We might have to share a server with a number of other web applications. How can we be sure that changes made to these applications won't affect our own? What happens if the developer of another web application decides to use a different XML parser than we do. Can we continue to use our own parser?

In this chapter, we'll look at these considerations. We'll try to understand the root cause of the problems, and we'll learn how to stop them from occurring in our own applications. Specifically, we'll look at:

• How the server (in particular Tomcat) loads classes, where it looks for classes to load, and the order it looks for classes in different locations

• The implications of using multi-threaded rather than single-threaded servlets, the conflicts that can occur, as well as the benefits it can bring

As we work our way through the chapter we'll use the debugging components and debug trace viewer we created in Chapter 10 to show what is really happening inside the container in each scenario.

---