Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Clearing Database Network Clogs: Page 3 of 6

First and foremost is security. Database connections are cached at the application-instance level or thread level. With some database technologies that cache connections by application, a user can gain unauthorized access to data. However, thread-based technologies don't pose this problem because they don't share connections across the application; each thread has its own security.

The technology you choose for connection pooling is also important. If you control the source code to your programs and they use ODBC or JDBC (Java Database Connectivity), you can enable connection pooling in your code (at the application-instance level). If your applications are running on an application server, that's OK--most servers support connection pooling in one form or another.

Finally, most database technologies let you set the number of pooled connections and the length of time to keep unused connections open. If you have too few pooled connections, network performance gains are minimal. And each open connection uses resources on the database server, so too many connections, especially with a long time-out value, hurts overall database performance.

Tracking connection problems can be difficult. Network performance for the database improves with reduced bandwidth. And as the database slows down, there's less traffic. That can fake you into thinking you achieved your goal of improving database behavior. Still, you can find out how many connections are open by checking your database-management interface.

Change Is Good