Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

A Java database framework: Maintaining control of the development environment

Protect your data with a Java database framework

  • Print
  • Feedback

There is nothing more detrimental to database performance than a team of Java programmers armed with a stack of requirements, a database, and a rudimentary knowledge of Java Database Connectivity (JDBC). Connections will be kept open and idle for hours, and when they timeout, the problem will be assigned to the database administrator (DBA). Unclosed statements and result sets tying up system resources will be the DBA's problem. Slow performance, due to programmers using obscure JDBC methods and dynamic SQL, is whose fault? You guessed it, the DBA. Add to this the fact that the development DBA is completely outnumbered by Java programmers, and we quickly end up with a slow-performing mess of a database and every problem being assigned to the DBA. As a development DBA myself, if you allow people to do whatever they want to your database, with no control, I believe all these problems are your fault.

This article discusses the use of a Java database framework to help protect the database from marauding developers. It provides connection pooling and management, tracking, and reporting of JDBC objects, and the ability to easily and selectively remove slow-performing structures and methods. The goal is to keep developers from hurting performance and falling into common bad practices, and to provide tracking where such activities can't be prevented. This way, you can find the problems and correct them prior to the system going into production. A second goal is to keep things simple so developers can quickly come up to speed. If it is truly simple, they will consistently use the framework rather than bypass it.

Development frameworks

With any framework, the goal is to hide complexity and provide a standard operating procedure for complex tasks. An equally important aspect is to provide consistency in how tasks are performed. This leads to better encapsulation and far more maintainable code. Just think if everyone constructed their own class and method for creating a database connection. Chaos and anarchy would ensue. Some common framework areas beyond the database would include inter-process communication, multithread management, and GUI standards.

Figure 1. Frameworks provide standards for complex tasks

The framework described herein is meant to be used by all middleware developers, and it provides a layer over the actual JDBC implementation provided by the database vendor. For this article and the free software I make available, I utilize the JDBC implementation from Sybase iAnywhere's SQL Anywhere, as well as JConnect, also implemented by Sybase. Before we dive into the framework details, I think it is important to understand some of the underlying inspiration that led me to concentrate on frameworks.

Object-oriented design and the database

In the early 1990s, I was contracted to write an object-oriented methodology for NASA. When it comes to software engineering, I still believe to this day that there is no place on Earth that puts as much emphasis on process. In the first draft of the methodology, I reworked processes into what I felt was a workable flow and added a streamlined set of documentation and reviews. When I submitted it, I had no idea that the two reviewers were well published in object-oriented design and were also reviewers of Grady Booch's foremost book on the subject. I received a lot of positive comments on my methodology, but the key area where I got slaughtered was in the transition from design to implementation. Their point was that there was not enough consideration for architecture, and I believe the word "protection" of critical components was even used and was driven home. In the second draft, I reworked the logical object-oriented design model into a clearer architectural model that accounted for the database and all physical components.

  • Print
  • Feedback

Resources