From the invocation layers, I chose to use only the JVM Invocation Layer for this example, the other ones are similar. You find and change the JNDI names of each InvocationLayer’s JMS ConnectionFactory in the InvocationLayer’s properties ‘ConnectionFactoryJNDIRef’ and ‘XAConnectionFactoryJNDIRef’.

The default HypersonicSQL setup files are displayed. You can find examples for other databases in your Jboss AS installation’s directories docs/examples/jca (for the datasource setup) docs/examples/jms directory (for the DB related database setup).

The ServiceManager chooses the JAAS security domain. Its configuration is located in conf/login-conf.xml.

IMO the most convenient and maintainable way of configuring own Mbeans is storing all Mbean configurations that belong to one application in one *-service.xml file, e.g. myapp-service.xml.

Bookmark It

Hide Sites

PreparedStatement, CallableStatement

Different JDBC drivers have different levels of tolerance, what to accept in the setObject() method of a PreparedStatement or CallableStatement. Avoid calling setObject() whenever possible, use the type-specific methods like setInt(), setString(), setClob(), etc. instead.

If you must use setObject(), use java.sql.Date for setting date columns.

Some JDBC drivers are not able to handle null values in setter methods like setString() or setObject(). Use setNull() instead.

ResultSet, CallableStatement

Calling getObject() on a ResultSet sometimes returns vendor-specific datatypes, e.g. Oracle TIMESTAMPTZ or XMLTYPE. Use Java-type-specific methods like getInt(), getString(), getClob() etc.. For vendor-specific types, find and use the appropriate Java-type-getter, e.g. getTimestamp() for a TIMESTAMPTZ or getClob() for an XMLTYPE (mapped to OPAQUE).

Connection Pool

If the database uses a vendor-specific type, it is likely that the JDBC driver requires its propretary Connection implementation. This may fail if you use a Connection pool. For instance, Oracle will throw a ClassCastException when trying to retrieve an XMLType from a Connection wrapper. In such a case you need to explicitely unwrap and use the vendor-specific Connection.

I have checked this for two open source connection pools:

• c3p0 hides the original Connection - no-go!
• DBCP exhibits it by providing a getConnection() method of the wrapper class - go!

Column Names

Use column numbers instead of column names.

Metadata ResultSets

Metadata is returned in the form of ResultSets.

Be prepared that the ResultSet may have less columns than declared in the DatabaseMetadata Javadoc.

Iterate through the columns only once, from left to right.

Metadata Capitalization

When navigating through DatabaseMetadata by consecutive querying, use the names in the capitalization returned in former requests as arguments for subsequent requests.

Schema Metadata

The DatabaseMetadata groups database schemas into catalogs. Each JDBC drivers actually seems to ignore one of the two:

• most drivers have no catalog or a default catalog which contains all schemas.
• MySQL and (by rumour) the ODBC/JDBC bridge drivers provide no schema, but each ‘thing formerly called schema‘ as a catalog!

Table Metadata

When querying schemas for tables, be prepared to retrieve metadata of deleted tables, e.g. BIN$… tables in Oracle. This is in fact the only piece of code where I make an explicit check for the name of the database vendor - just in case.

Column Metadata

The driver may render default values in brackets, e.g. ‘(1)’ instead of ‘1′. You may also encounter additional white space, e.g. ‘1 ‘ instead of ‘1′.

Column Type Metadata

When querying the column type from database metadata, you get a columnType of type int and a columnTypeName. The columnType is the vendor-independent code from java.sql.Types, e.g. Types.CLOB, the columnTypeName is vendor-specific.

In the ResultSetMetaData class, these are provided by the methods

• int getColumnType(int column)
• String getColumnTypeName(int column)

The DatabaseMetaData class returns them as ResultSet columns when calling getColumns()

For vendor-specific types this will return 1111 (Types.OTHER) and you need to judge the appropriate Java type from the vendor-specific typeName. I map typeName substring to Java types for this, e.g. any type containing a substring ‘XML’ will be handled as Types.CLOB and used with get/setClob().

Index Metadata

When querying index metadata, be prepared to face column names that cannot be found in a table! This is the case for e.g. functional indexes in Oracle databases which are used for indexing timestamps.

…anything else?

This list makes no claim to be complete. If you know of other resources or have made further experiences with vendor-dependencies, please tell the world by posting a comment.

Bookmark It

Hide Sites

1. there are common mistakes, made again and again. That gives cause to systematically collect, analyze and describe these mistakes. They are solutions to a problem (mostly a functional requirement) and, thus, might implement a design pattern properly. Though, they cause trouble in some other way (e.g. non-functional or unspecified requirement), constituting an antipattern. For a developer these a samples of what to avoid.
2. detecting the cause of a problem is a (to some extend) intuitive task, because of the complexity of systems: With rising experience you ’smell’ problems by observations of system behavior under different circumstances, known weaknesses of products and estimated competence of team members. Step by step you confirm or reject suspects by tests and tools, taking some deviations and finally find the cause. A taxonomy of performance issues would help adding objectivity and system to this process and ease the process of performance analysis for beginners.

There are lots of antipatterns already defined, but they are strongly distributed work by individuals. Some sites and books list antipatterns (too bad, it is about any antipatterns, not just performance-related ones):

Books

• Bitter EJB, by Bruce Tate
• Antipatterns, by William J. Brown, Raphael C. Malveau and Hays McCormick
• Bitter Java, by Bruce Tate (Comments on amazon, Table of Contents)

Web Sites

• Wikipedia Anti-pattern article
• Antipatterns Category Catalog of the Portland Pattern Repository
• Antipatterns (related to the book above)
• Performance Anti-patterns by Kirk Pepperdine
• Article on Performance Antipatterns by Bart Smaalders
• Paper on Software
  Performance AntiPatterns by Connie U. Smith & Lloyd G. Williams

When searching for performance antipatterns you are on your own: I have not managed to find any systematic list of performance antipatterns; even the known sites or books do not group or at least mark performance antipatterns, you have to read through all of the patterns to refine the performance related ones.

Though reading through all antipatterns would help you a lot improving your design and programmings skill, you probably will not have the time to do so. But I did and decided to start my own list of performance antipatterns. After some time of research, the performance antipatterns found summed up to more than 100 unique patterns.

I observed that many antipatterns of different technologies have something in common, there is a meta concept that impacts performance. I refined the meta concepts and grouped them hierarchically to - voilà – about 30 performance meta antipatterns. They are useful for designers and architects, showing rather plattform-independent critical concepts than platform-dependent samples. This still is a work in progress.

Time for some definitions:

• Design Pattern: proven solution to a recurring problem
• Antipattern: recurring bad practice in solving a recurring problem
• Performance Antipattern: Antipattern that results in poorly performing systems and/or increased effort in making systems perform (while not affecting fulfillment of functional requirements)
• Meta Antipattern: Common concept that is the foundation of different antipatterns

When telling you about antipatterns, I face a problem: The concepts are public domain, since anybody implements the pattern, but the naming and description of an antipattern is individual work and subject to copyright laws. Thus I will restrict my description of foreign work to a minimum and link to the original source in such cases.

Many patterns come frome the following books, I’ve read all of them and find each one highly valuable. Read at least some of them. I guess they might be most useful for you in the following order (by priority and applicability): ‘Bitter EJB’ (EJB-related), ‘Antipatterns’ (more architectural and technology-independent) and ‘Bitter Java’ (a little outdated, but good patterns for desktop or selfmade server systems).

In the next weeks I will add blog entries for specific performance (meta) antipatterns. Meanwhile read the books and sites recommended above and have a look at some useful performance-test-related open source tools: JUnitPerf, JMeter and benerator.

Bookmark It

Hide Sites

Literate programming is a concept of programming which states that a program should have readability as a primary goal,
thus making programs works of literature.

Initially this embraced adding documentation to source code like with JavaDoc and has been adopted by many programming languages, e.g. with Doxygen. (For Historians: The original idea was stated by Donald Knuth in some former century and prototyped by his WEB environment, using Pascal as programming language and TeX for documentation.)

Since we all love to write documentation, people have found concepts of literate programming with a much higher coolness factor:

Designing program APIs to form human-readable statements.

A simple example everyone is supposed to be familiar with, is the StringBuffer/-Builder, e.g.

buffer.append("Hello ").append(user);

Great examples of complete APIs are EasyMock, JUnit 4 and commons-lang. For example, JUnit 4 allows you to write fancy test code like this (see the JUnit 4.4 release notes):

assertThat(answer, either(containsString("color")).or(containsString("colour")));

…do these statements really need documentation?

From the purpose of the mentioned libraries, you get the impression that especially dull tasks inpire people to ‘play’ with such ideas. I assume this is true since:
- building objects and testing software is complex and strongly repetitive
- repetitive tasks invite for facilitation by abstractions or at least abbreviations
- your grandma now gets an idea of what you are coding. Even better: you still understand your code when revisiting it six months later!
- when doing dull tasks, you are searching for things to have fun with

The latest statement is funny but exhibits a deeper truth: Making dull tasks a fun is infectuous and you can’t stop it. I will never be able to write stupid test cases again.

In each business or technical discipline you have common concepts to test that can be abstracted and ‘literated’.

An example from my work: While developing benerator, an open source framework for test data generation, I need to test data sequences that are generated in subsequent calls to a generator object. A naive test implementation looked like this:

assertTrue(generator.available());
assertEquals(1L, generator.generate());
assertTrue(generator.available());
assertEquals(3L, generator.generate());
assertTrue(generator.available());
assertEquals(2L, generator.generate());
assertFalse(generator.available());

With a literate API I could reduce this to

expectSequence(generator,  1L,  3L,  2L).withCeasedAvailability();

Much shorter, much quicker to write and understand, yet easier to maintain! It is even supported by code completion. I love it!

If you now state: “I code like a real man - sissies don’t need to understand my code”,you are headed for trouble with your boss and collegues, but I have a relief: Delving into the skills needed to design and implement such APIs you will find a wide playground to unleash your code monsters, yet making users of your code happy:

For implementing such behaviour you need to create
- a parent class of your test case (or a utility class from which you import statically)
- one or more helper classes for invocation chaining

The parent class provides the methods initially called (like expectSequence()), the helper classes provide for invocation chaining. These helper classes are your monster’s playground and will scare any sissy at first blush:

public class GeneratorTestCase extends TestCase {
  // snip...
  protected static <T> Helper expectGenerations(
      Generator<T> generator, T ... products) {
    for (T expectedProduct : products) {
      assertTrue(generator.available);
      assertEquals(expectedProduct, generator.generate());
    }
    return new Helper(generator);
  }

  public static class Helper {

    private Generator generator;

    public Helper(Generator generator) {
      this.generator = generator;
    }

    public Helper withCeasedAvailability() {
      assertFalse("Generator is expected to be unavailable: " +
        generator, generator.available());
      try {
        generator.generate();
        fail("Expectected IllegalGeneratorStateException");
      } catch (IllegalGeneratorStateException e) {
        // exception is required
      }
    }
    // snip...
  }
}

Reading through the code, you will easily understand the expectGenerations() method: It iterates through a varargs parameter verifying generator invocation results for each. Finally, it returns a Helper instance that enables you to add another .method() call to the expectGenerations() command. This needs to act on one or more of the objects processed by the first method call. Thus, the concerned objects need to be internally submitted to the helper when constructing it.

You can continue the concept iterativly or recursively: Iteratively, by returning the Helper from the method withCeasedAvailability() as shown in the example, or recursively by returning further helper classes that provide features dependent of the sematic that is implied by the current Helper method call.

Once you have grasped the concept, it is supposed to change your development life. When you get the taste of it, it will be hard to get back.

Now go on, infect others with the literate-programming-virus, have fun doing QA and don’t forget to let grandma check your code!

Bookmark It

Hide Sites