Mission Data Blog
Louisville-based Web Development & Software Engineering

Our project has entered the stage where we start tuning the data access to improve performance. This project uses Hibernate to access a AS400/iSeries system via the JT400 JDBC driver. My prior experience using the SQL Server
database introduced me to Microsoft’s Query Analyzer, which is a nice tool for identifying where you need to index the database. A bit of searching turned up an IBM tool called Visual Explain that fits the same need. The sysadmin started the profiling tool against my connection, and I ran through a standard usage scenario in our application. Visual Explain showed each query, how long it took, the access strategy, and recommended indexes. This kind of tool is absolutely essential for database performance tuning.

The second important item we learned from this process is the performance difference between a true SQL index on the iSeries and a keyed logical index. From iSeries V4R2 on, SQL indexes have page sizes of 64k. By comparison, a DDS logical will max out at 32k, and will typically be much smaller. The performance is so much better that our customer is converting all all their DDS logical indexes to SQL, even if only their legacy RPG applications use it. This IBM document has a good discussion of this issue.

In an earlier post, we detailed a method for removing stale Rails session files. In more recent version of Rails, there is a Rake task built in for this administration task.

rake tmp:sessions:clear # Clears all files in tmp/sessions

For my current project we needed to audit the property setters Hibernate was using on our objects to make sure that any logic in them was not overly state dependent. More about this issue in Hibernate is available here. We have fairly rich object models, and a lot of methods, including setters, are never used by Hibernate. We wanted a report of the setters actually used by Hibernate to limit the amount of code we had to examine.

The Hibernate API allows you a lot of access to its configuration object model, and this is ideal for finding out how Hibernate is interacting with your code. I wrote a small class to do this inspection. The method below is run after a Hibernate Configuration object named creatively as “configuration” has been built with mapping files:

public Map findSetters() throws MappingException
{
  Map classToSetters = new HashMap();
  Iterator classMappingIterator =   configuration.getClassMappings();

  while(classMappingIterator.hasNext())
  {
    PersistentClass persistentClass = (PersistentClass)classMappingIterator.next();
    Class mappedClass = persistentClass.getMappedClass();
    Iterator propertyIt = persistentClass.getPropertyIterator();
    List classSetters = new LinkedList();

    classToSetters.put(mappedClass, classSetters);

    while(propertyIt.hasNext())
    {
      Property property = (Property)propertyIt.next();
      Setter setter = property.getSetter(mappedClass);

      classSetters.add(setter.getMethodName());
    }
  }
  return classToSetters;
}

I have uploaded a Java project that contains the full HibernateInspector class, as well as some sample classes and mappings. Un-tar it, and run

ant -Dhibernate.home="path to hibernate 3" 

to build and run the example.