I'm using JProfiler to look for memory leaks. I've used it to see that they've been plugged since I implemented Robert's suggestion of having a separate temporary DataContext that gets garbage collected, collecting the Reading data objects with it.
I now think that garbage collection being the reason for three connections to be required is quite silly! If a connection is ready for garbage collection then it won't be visible to the Cayenne code. The Cayenne code is baulking because two connections are currently in use and a third is required to execute a query (that's my understanding of the error message). To really see the cause of the problem it would be good if the "Too many connections" stack trace told us what the other two connections are being used for. Alternatively the instrumention at the DEBUG logging level might show connections being picked up and released, and I would be able to work out why the other two are being held from there. ~ Chris Murphy On 13 December 2011 00:50, Durchholz, Joachim < joachim.durchh...@hennig-fahrzeugteile.de> wrote: > > Perhaps the garbage collector thinks that its okay to leave around such > a small amount of garbage for more than a minute. > > > > Am I right?? It sounds weird that a garbage collector can cause a > program to crash! > > Probably not. Garbage collectors will kick in after a certain threshold > has been reached, and that threshold is usually set at the end of the last > cycle. > In other words, unless you have a real memory leak, the collector should > keep the memory footprint stable. It's part of its job description. > (The actual mechanism is far more complicated, but that's the bottom line). > > If you are using Sun's Java 6, you can monitor memory usage via JVisualVM, > which comes as part of the JDK. > JVisualVM also works well for Sun's Java 5 runtime. You'll have slightly > reduced functionality and you need to supply an extra -D parameter to the > Java 5 RE, but it does give you the pretty real-time graphs. That tool > helped me a ton, a year or two ago, with little hassle for set-up, despite > being tied to Java 5 at that time. (JVisualVM will even give you statistics > about which data types take up most memory, show you all objects of a type, > and will even do a breadth-first search for a stack frame that's keeping > any given object alive. I'm not 100% sure how much of this is available for > Java 5, but if Java 5 fails you can still try Java 6.) > > HTH > Jo >
