Bouncing beside the mountain guide in my SUV, my partner Mike and I notice
that we are awfully close to the cliff next to the dirt road. The 72-year-old guide
trusts neither of us to drive. As I watch him gently guide the vehicle down near-
vertical drops and around turns a scant 3 feet from the cliffs, I am inclined to
agree with him. Every now and then the SUV slides sideways, but he patiently
coaxes it back onto the trail with a feather touch. Other times, he is close to asking
us to get out of the vehicle and help guide it down a particularly slick or steep sec-
tion, but each time he seems just confident enough to continue.
We are here to run the Gunnison River in Colorado—if we ever get there.
After a full hour on the road, I have my doubts. When planning the trip we real-
ized that we'd have to run many river miles, but didn't fear getting caught by
darkness because the current was swift and the rapids easy. We won't need to scout
much. On the map the shuttle road looked short and close to the river. Ah,
patience. With luck, we'll easily finish by nightfall.
When we hired the guide, he noted my 8:00 a.m. start time but suggested 6:00
a.m. instead, “to be safe.” Now I see why. After driving for an hour and a half he
finally stops the SUV and begins to unload our gear—at the top of the canyon. I
look in dismay at the tiny footpath leading to the winding river below.
Most Internet architects see black lines on a white piece of paper and imagine
their characteristics. They ask questions. What is the physical network? What
protocols are established? Is there enough bandwidth? How fast is it? What are
the peak loads? These questions assume that a software connection is already
successfully established. Questions related to creating and terminating a con-
nection are easily dismissed.
This philosophy is easy to understand; just a few short years ago, most con-
nections were fairly static. Today, however, many solutions call for quick con-
nections, and new frameworks make it easier for you to establish those
connections. In this chapter, we'll look at some antipatterns related to how
connections are established and terminated. We'll then examine some technol-
ogies you can use to decouple interfaces between systems.
Antipattern: Connection Thrashing
Over the years, database performance has been a weak spot among Java devel-
opers. I am not sure why. Perhaps we're accustomed to working with well-
behaved subsystems that need little or no tuning—file systems, for example.