Leaks

One of the things that programmers should always keep in mind is the issue of resource leaks. The most common leak is lost memory, which is allocated but not freed; but there are other kinds of leaks, too (file handles, processes, database connections, sockets, etc.) For any long-running program, this is a flaw that causes gradual decay in performance in the application and usually has an impact on the entire system. In some cases, a bad application can cause a good one to fail because the bad one has stolen resources. When this is done intentionally, it is called a "Denial of Service" (DoS) attack.

This is really more of a problem for thin- and web- client applications than is faced with conventional client-server applications. The reason is that fat clients run on PCs, which usually get rebooted daily (if not more). These PC reboots reclaim the resources which sloppy programs have leaked. Rebooting a server - especially one which is busy - is a nasty inconvenience and should be avoided.

Java Servlets are extremely long-running processes and perform admirably. In my own experience, I had a servlet engine (Apache JServ using IBM Java 1.1.8 for Linux) which stayed up for over 180 days without a reboot - and when I did reboot it, the reason was to install a new version. This is a real test of the quality of a computing infrastructure... slow leaks don't show themselves until many, many hours in use.

Java is much better than C++ at protecting against memory leaks; but it is still possible to do write sloppy applications. Be careful to make your application a good citizen by freeing any acquired resources - if you are given a way to get them, then you are also given a way to release them. If your code opens a file, be sure to close it. If it connects to a database, take care to disconnect. Remember that there is no debugger that will point these things out to you... they are your responsibility.

Contents

Application Design

Leaks

Previous: Collaboration | Next: Advantages of loosely-coupled design