DB2 Java Performance: DB2 Design UOW

Designing the Unit-of-Work for a given transaction entails many components. Different techniques and methods are incorporated depending on the components such as Hibernate, iBatis, JPA or Enterprise Bean technology to process the transaction.  The Java transaction framework and the object patterns incorporated with the components also affect the transaction unit-of-work. All these factors together provide complete flexibility for today’s Java developers.

Unfortunately, with this flexibility comes the responsibility to handle the transaction as effectively and efficiently as possible.  For example, the various Hibernate, iBatis, JPA or Enterprise Bean technologies often shields the programmer from the database access.  The database object is often passed through several methods or classes before it is used so a number of modifications could have already taken place.  This same database object is also the same database SQL table access used for many different of processes and this is typical for the majority of the Java system reviews done recently.

This same database object is usually a SQL access that is usually a generic SQL call to a single table retrieving all of its columns with a minimum of WHERE clause filtering or using a unique key for getting a single row from the table.  In both cases the SQL is fairly simple. When it only has minor WHERE clause filtering, the database access is too generic.  When the access is a unique key, the access is usually too fine tuned to retrieve the group of data desired.  Sometimes the Java processing passes multiple instances of the database unique access object and the Java method processes all of these database objects.

In all these scenarios, the SQL database access does not fit the transaction processing or its unit-of-work.  Generic access through the various Java persistence layers usually only provides basic performance for your transaction processing and usually retrieves too many rows for a given transaction.  To achieve peak performance the transaction needs to access specific sets of database information and process them quickly.  In too many systems this is a rare transaction processing situation.