I am new to optimizing java so perhaps I can learn a little bit. I may
be picking out items that may have no "real" impact on performance.

I ran the code (that was posted on this thread) through a profiler and
noticed that one of the top memory-allocators was the function
org.firebirdsql.jca. FBConnectionRequestInfo.getStringProperty. The
function appears to be called once for each request sent to the
database.

public String getStringProperty(int type)
{
if (c == null)
{
return null;
} // end of if ()
if (c.find(type) == null)
{
return null;
} // end of if ()
return new String(c.find(type));
}

c is a ClumpletImpl. Here is the find function (hacked to show the
depth of recursion):

public byte[] find(int type)
{
return find(type,0);
}
private byte[] find(int depth, int type)
{
if (type == this.type)
{
System.out.println("yes-depth:" + depth);
return content;
} // end of if ()
if (next == null)
{
System.out.println("no-depth:" + depth);
return null;
} // end of if ()
return next.find(depth + 1, type);
}

Now - it appears that the function getStringProperties is getting called
once per database request. For each request it does a recursive search
(depth 50 on my test). If the value is found - the search is performed
twice and a new string is allocated for each time a property is
retrieved.

Question 1: Would the getStringProperty be better implemented as a
HashMap of Integer-to-CLumpletImpl objects?

Question 2: Would there be an advantage of caching the string allocated
in the HashMap instead of caching the ClumpletImpl in a HashMap?