Chapter 7 -- Sharing Resources in a COM Application

[Previous] [Next]

Chapter 7

A typical COM+ application can run on many different hardware configurations. That's the beauty of COM and location transparency. But while you have many options, you can use only one physical deployment configuration at a time. Maybe you're running your application on a server computer with a single 166 MHz processor. Maybe you're running it on a computer with four 400 MHz processors. Maybe you're lucky enough to have a server farm with lots of processors spread out across many computers. Whatever your configuration, you should always write applications to make the most of the hardware that's currently available. This is the secret to writing an application that's scalable.

What is scalability? Apart from being a much-abused marketing term, scalability is an application's ability to serve a growing number of users without experiencing a drop-off in response times and overall system throughput. If your application provides one-second response times when it has 20 users, it's considered scalable if it can offer the same response times when it has 10,000 users. If your application can't handle all of these users when running on a server with a single 166 MHz processor, you can't determine whether it's scalable or not. If your application can't offer one-second response times no matter how much you spend on hardware, it's definitely not scalable.

There are two sides to scaling an application: acquiring more powerful hardware and writing your code to take advantage of whatever hardware it's running on. To write scalable components and applications, you must know how the COM+ runtime works. This chapter explains how to work with the COM+ runtime to handle as many concurrent users as possible.

Let's break down the parts of a distributed application. A distributed application is a set of one or more processes running on one or more computers. If objects are the atoms of your application, processes are the molecules. You partition your application into processes by configuring your components in various server applications and library applications. In some deployment scenarios, you might want more processes. In other scenarios, you might want fewer processes. In this chapter, I'll focus on the factors that allow each individual process to serve the largest possible set of clients.

A multitier application can offer greater scalability than a two-tier application because it can share process-specific resources across a set of clients. The COM+ runtime makes it possible to share threads, memory, database connections, and poolable objects. The main theme of this chapter is that code running on behalf of a single client should never be selfish. It should acquire its resources as late as possible and release them as soon as possible. Applications that share resources efficiently scale better than those that don't.

This chapter focuses on process-specific scalability issues. In later chapters, we'll examine designs that allow a distributed application to be spread across multiple computers. As you'll see, you should avoid certain programming techniques if you want to run your application in a server farm. For now, we'll limit our discussion to a single process running on a single computer.