On Oct 18, 7:17 am, ric...@gmail.com wrote:
> Hello,
>
[quoted text clipped - 18 lines]
> Thanks in advance,
> Ricardo Marques
Can you verify from the Oracle Server end to ensure the connections
are actually closed?
It could be that the connection closing code is a part of a try{ }
instead of finally{ }, so if there is an error, the connection(s)
never get closed... commonly overlooked mistake.
Also, instead of opening up a new connection every time the thread
wakes up, keep the connection as a static class variable, initialize
it via a context listener (in contextInitialized method), and re-use
the same connection througout the lifecycle. You can close the
connection in the contextDestroyed method in the same listener. Google
around for listeners and their configuration if this suits as a good
solution.
-cheers,
Manish
ricmar@gmail.com - 24 Oct 2007 11:22 GMT
> On Oct 18, 7:17 am, ric...@gmail.com wrote:
>
[quoted text clipped - 38 lines]
> -cheers,
> Manish
Hello,
sorry for the late reply.
I have checked the connection and they are beeing closed. I also can
see tomcat creating/removing extra connections if needed (since I use
a pool connection).
Regarding the finally tip, every query I checked, the closes
statements are done in the finally { }.
I always get a connection from the existent DataSource and I use the
same DataSource. I think I should avoid the static variables when
concerning connections to DB.
thanks,
Ricardo
Manish Pandit - 24 Oct 2007 20:03 GMT
On Oct 24, 3:22 am, ric...@gmail.com wrote:
> Hello,
>
[quoted text clipped - 13 lines]
> thanks,
> Ricardo
In that case, you might want to download lambda-probe, a real time
monitoring/profiler application (http://www.lambdaprobe.org/d/
index.htm). This will give you and overview of memory usage,
unterminated threads..and anything that would seem unusual. I've found
it to be very useful in situations where I have unwarranted memory/CPU
issues.
-cheers,
Manish