@Sanne Grinovero
Its indeed a bit tricky. I cant really say too much about “regular production” userers, because thats not really how we use hibernate. One could introduce a flag into hibernate to either behave like the classloader will get thrown away or like the classloader will be reused. However that will just add one more feature into the already heavy overloaded feature matrix of hibernate… Another thing would be to make some sort of detection if multiple bootstraps are happening on the same classloader and print a warning that this might leak memory. Maybe we should rewrite our application/test to dynamicly create and throw away classloaders, but that seems to be annoying as well… As per thesse fastClass thingies. I do not know if the current source code looks like, but according to my Analsys the following happened IntegrationTest A creates a Fastclass for Entity Animal, IntegrationTest B creates a Fastclass for Entity Animal. IntegrationTest C creates a Fastclass for Entity Animal…
Now you have 3 Fastclasses loaded in your jvm. These take up memory and may ultimately add up until the testmachine runs out of memory. If they would be Cached: IntegrationTest A creates a Fastclass for Entity Animal, IntegrationTest B reuses the Fastclass for Entity Animal. IntegrationTest C reuses the Fastclass for Entity Animal… Now you have only 1 class in your jvm.. hurra |
