NonXa connection factory exhausts the pool during oracle db connection reap in a particular scenario about transactions-essentials HOT 5 CLOSED

Thanks,

So basically your point / problem is: recycleConnectionIfPossible should not give up after an exception, but rather iterate over the remainder of the pool.

Correct?

from transactions-essentials.

Yes, Correct. I would go one step back and consider the connection to be not eligible for recycling, as the connections that are marked as erroneous cannot be recycled as per the code.

from transactions-essentials.

OK thanks - created a feature request for this. I am closing this issue for now - re-open if you disagree?

from transactions-essentials.

HI Guy,

I came across this thread and the description is very close to what we have been experiencing with our application. Similar to what @rmaheedharan has experienced, we see this behavior when we have database blocks. When we have a long block that doesn't clear on it's own, we sometimes allow a dba to terminate a session to clear the block. At first it seems as if everything clears up. Other blocked transactions flow through and the issue looks to clear up. However, in cases where a process continues to run, we will start to see the connection pool grow rapidly until we exhaust a pool configured to have 400 max connections.

This seems likely related and when it occurs, our only recourse is to restart the application. Would you not consider this to be a legitimate and somewhat nasty bug instead of a feature request?

from transactions-essentials.

Hi @lewisdavidcole - thanks for the feedback.

I would consider it more of an efficiency enhancement, but I can add a "bug" label if you prefer.

However, your description sounds like there are other problems (i.e., long DB blocks). Are you using XA or non-XA for that?

Let me know...
Thanks

from transactions-essentials.