Client: a large direct mail retailer
Project: The client has a large, complex J2EE / EJB application, built over several years, using a variety of data access software approaches; primarily a mix of direct JDBC access with BMP EJB Entity Beans. In load testing, they found that while the system was under roughly constant load the number of database connections and delay in completing business operations would sporadically spike to high levels. They had applied various approaches and tools to track down the problem, without success, so they brought in Oasis Digital to help. We found that their code contained many almost-duplicate sections, for the management of JDBC connection, statements, result sets, etc. We found scattered example of incorrect, incomplete error and resource management. To address this, we showed the client’s developers how to apply the principal “Don’t Repeat Yourself” (DRY) to centralize interaction with the JDBC classes in to one place in the application. This layer simplified the application code dramatically, and made it possible to ensure that resources would always be released correctly. With this change, the connection and load problems went away; we determined that they had been caused by “leaked” JDBC statement handles and result sets, which were not noticed by WebSphere or DB2. When these orphans objects accumulated sufficiently, they caused delays and connection “spikes” while they internally (and silently) timed out.
Business Result: A serious problem, which put the organization’s order processing at risk during an upcoming busy season, was resolved within a few weeks.
Technologies: Java, J2EE, WebSphere, Clustering, DB2, Mercury LoadRunner