Object instantiation and heap size in ColdFusion - Part III

Stil trying to sort out my indexing issue in my application, I decided to start adding components back into the mix to see when memory would start to be affected. I had a theory that the beans used to hold each object were not being garbage collected, and I wanted to prove it.

I added in the SolColdFusion component for indexing and commiting documents to the repository and removed my inline code. Indexing is a single method that accepts an XML document and posts it via HTTP POST to the Solr server. Commit accepts no arguments and posts an XML document it generates to tell Solr to commit changes to its index. Using this one component, I found that indexing was just as fast as in the procedural code and the heap size, once again, never went above 60 MB.

For kicks, I created a component called ObjectDAO with a single method, getObject, that called the stored procedure I was using in my inline code to get each object from the database for indexing. Instead of calling the stored procedure inline, I instantiated an instance of the component, and then I called its getObject method for each of the 10,000 objects I was indexing. Once again, I found that the routine processed the data very quickly and the Java heap never went above 60 MB.

Next, I instantiated a copy of my object bean, cmObject, and populated it with some of the base object data for each object as it was pulled from the database, but I did not use the object for any processing. Yet again, processing was quick and the heap never went above 60 MB.

Following the process of adding components one by one, I instantiated my application's normal object DAO, cmObjectDAO, and used the read method to read data from each object in the database to the object component. I didn't do anything with it, just read the data into the object. The processing took longer due to the overhead of twice as many database calls. The heap grew a bit more than in the earlier tests but never exceeded 100 MB and maintained a normal sawtooth pattern as data moved in and out of memory.

In order to make a better comparison between the procedural and OO code, I modified the routine to use the object component instead of using the query data returned from the stored procedure. In this routine, indexing took more than double the time of the procedural routine and the heap size steadily climed from 30 MB to nearly 200 MB, suggesting that object instantiated were not being garbage collected even after they were discarded. In short, it looks like my theory was correct and the beans used to hold the data were persisting in memory until the end of the request, or until the heap maxed out.