Ye gods! What do you need all those spaces for in front of every line? Four spaces per level is plenty - eight just forces your code over off the right side of the screen. And why isn't it indented consistently? This is a pet peeve for me - making your code easily readable for others is key to getting people to help. Of course this is much better than some I've seen but still...
> I am trying to generate an XML string from a table with
> 13160 rows in the result set.
Well, there's your problem right there.
OK, the simplest possible fix - consult the documentation for the JVM you're using to see if you can set the max allocated memory to a higher value. For example, for JDK 1.3 on Windows the documentation is
here. Use
java -Xmx 128m to set max memory to 128 MB - the default is 64 MB if you don't set it otherwise.
While you're at it, set the -verbose:gc option so you can get a printout of the JVM's attempts to reclaim memory. This is very useful in figuring out where & when memory is being consumed by a program.
At a guess though, I strongly suspect that the best place for you to reduce the memory usage of your program is the StringBuffer. Sure, it's better than using Strings, but your XML string is going to be pretty big overall. Is it necessary to store the whole thing in memory? What are you going to do with it afterwards - write it to a file? If so, consider replacing the StringBuffer with a FileWriter wrapped in a BufferedWriter. That way each time you read a new row from the ResultSet, you can basically dump the information straight to a file rather than taking more and more memory in a StringBuffer.
Even if you don't need to write the XML to a file in the long run, and you really do need a full-size String eventually to apss to some other method, consider writing the XML to a file as an intermediate step, and then read the file later to create the String from that. The problem is that the ResultSet is already going to take up a large amount of memory - if you build the StringBuffer at the same time, then that will be two large amoounts of memory being allocated at the same time. If you delay creation of the String until after you've discarded the ResultSet, you can substantially decrease the total memory needed.
The other thing to look at is the ResultSet. Is it necessary to read all 13160 rows at once? That probably means your ResultSet will have to be big enough to store all the data at once. (Although it's possible some drivers find ways around this; I dunno.) Is there a way of breaking the ResultSet into smaller groups? For example, if you the data represent employee records which you're accessing by last name, you could first query for all names beginning with "A" and process those results, then "B", etc. It really depends how your data are organized, but there may well be a way to do something like this.
Good luck...
