If SpecCompliant is set to true in transaction-service.xml, jboss begins to leak
memory on a massive scale: all entity beans (both CMP and BMP) that become unused
(that is: they are flushed from cache, and instance pool is full, so they are
discarded) are never garbage collected.

I don't pretend to understand the problem fully (I was in quite a rush to solve
the memory leaks and it still took me over a week). I investigated the matter
with a home-grown memory profiler, and found out that the leak ultimately occurs
in org.jboss.resource.connectionmanager.CachedConnectionManager, which never
releases the KeyConnectionAssociation objects (that are stored in a ThreadLocal
LinkedList).

And since KeyConnectionAssociation also holds a reference to the entity object,
the entity objects leak once they are thrown out of the pool.

And those KeyConnectionAssociation objects are of course created as a result
of the entity beans opening connection to the database.

I never found out why the KeyConnectionAssociation objects were never removed
from the list (which would have resulted in garbage collection of the entity
and all). I just saw somewhere in the code promising references to
SpecCompliant, and thankfully it solved the problem for me.

Note that leakage also occurs (immediately) if JBoss gets an entity from instance
pool to run a finder, and the finder throws an exception. In that case, the
entity used to run the finder is leaked immediately (the leakage happens in the
same way as outlined above).

I marked this problem for 3.2.6, but as far as I can see, the problem is the
same in 3.2.7 and 4, too. Maybe priority should really be "minor", since I'm
not sure that many people use SpecCompliant.

Oh, and I also have Debug=true in transaction-service, if that makes any
difference.