CODEWITHSUNDEEP
javaoracle-databasetomcatojdbc
Martin Larizzate
Martin Larizzate

Reputation: 910

Java - Orcale could not open JDBC connection for transaction

I'm working on a very very big but poorly implemented project and we have a big performance issue related to de Database. We are using Oracle, exadata and bla bla bla. Application Server: tomcat Diver: ojdbc6

And the next configs:

<property name="connectionCachingEnabled" value="true" />
<property name="connectionCacheProperties">
<value>
MinLimit:180
MaxLimit:200
InitialLimit:50
ConnectionWaitTimeout:120
InactivityTimeout:180
....

The application has almost 15 modules running independently but also some modules includes others and uses their datasources.

Yes I know... what you are thinking. When I arrived it was already like this and I need to patch it meanwhile the team works strongly on reengineering

The issue is that the 15 modules should take 200 connections but with this spaghetti, each one takes also the included modules connections.

this is a connections soup!

But at this point the issue is that some modules cannot take their 200 connections because the database has no more resources so.... related to the "ConnectionWaitTimeout" config it returns a beautifull null to the pool with the next message:

Could not open JDBC Connection for transaction; nested exception is java.lang.IllegalArgumentException: Connection must not be null

Checking on the database most of modules takes 200 connections but have only 7 active and 197 inactives.

I cannot find the right config to break free the inactive ones.

I used InactivityTimeout and AbandonedConnectionTimeout but the issue persists.

Upvotes: 0

Views: 1731

Answers (1)

Prasanna
Prasanna

Reputation: 2498

Without analysing the application we can just speculate on why this issue is happening.

  1. Since 197 connections have been created (more than 180), looks like application has requested so many connections from the pool.
  2. Since, Inactive timeout did not help, we must assume the connections are still retained by the application.
  3. Now since abandon timeout did not help, there are 2 possibilities.
    A) Application is indeed querying DB within the timeout period.
    B) Pool reclaimed the connections, application should have caught the exception and retried

I suggest you understand the code in 1 of the modules to understand the connection usage pattern.

Upvotes: 1

Related Questions