Given the object model of Java and the relational model of the database, accessing data properly continues to be difficult for most Java application developers. Over the history of Java development, there have been many attempts within vendor products, interfaces and open source projects to bridge this object to relational data chasm. Many object to relational mapping of (ORM) solutions exist but few applications leverage them properly or efficiently.
The leading architectures providing good performance for my clients today, the Enterprise Java Bean (EJB) specifications, Java Persistence Architecture (JPA) continue to evolve. Sometimes I have seen the open source Hibernate product implemented by projects looking for a quick database interface but usually it is leveraged improperly and performs poorly. Sometimes the Hibernate interface even masks or creates problems through its SQL handling and various parameter settings. Some clients have even written their own plain old Java object (POJO) interface to get to their data.
Any of these ways to get to the data can work and get good performance if the proper application framework, architecture and design pattern is matched with the correct application and transaction type. Working with IMS, IDMS, CICS and MQ systems referencing DB2 shows that very large databases with high availability have a variety of frameworks, architectures and design patterns. Just because an application is using an object oriented language such as Java, C## or .Net does not mean that performance or good database standards and principles should not be implemented or expected. Sometimes the application focuses on making the application into the framework and more attention should be paid to performance.
(To be continued next week.)