Db2 for z/OS & Db2ZAI

I got a call from the DB2 admin that my application creates a new connection for each transaction.

I checked the app running on Kubernetes using the latest JDBC driver jcc 11.5.9 that the connection pool is properly configured. Logging says yes, and also the metrics say yes. From the Java point of view everything looks ok. 70 JDBC connections and millions of usages.

The zOS admin says he sees millions of connections and even worse millions of threads. The problem with the threads is that they eat up a lot CPU. 

Now I'm lost. Yes, the app creates 25000 transaction per minute. Is this to much for DB2? I assumed that DB2 also reuses resources/threads. I actually have no idea what happens between the JDBC layer and the database on zOS. Has somebody a link that explains what happens in between? Or an idea what's going on there?

I got a call from the DB2 admin that my application creates a new connection for each transaction.

I checked the app running on Kubernetes using the latest JDBC driver jcc 11.5.9 that the connection pool is properly configured. Logging says yes, and also the metrics say yes. From the Java point of view everything looks ok. 70 JDBC connections and millions of usages.

The zOS admin says he sees millions of connections and even worse millions of threads. The problem with the threads is that they eat up a lot CPU. 

Now I'm lost. Yes, the app creates 25000 transaction per minute. Is this to much for DB2? I assumed that DB2 also reuses resources/threads. I actually have no idea what happens between the JDBC layer and the database on zOS. Has somebody a link that explains what happens in between? Or an idea what's going on there?

I got a call from the DB2 admin that my application creates a new connection for each transaction.

I checked the app running on Kubernetes using the latest JDBC driver jcc 11.5.9 that the connection pool is properly configured. Logging says yes, and also the metrics say yes. From the Java point of view everything looks ok. 70 JDBC connections and millions of usages.

The zOS admin says he sees millions of connections and even worse millions of threads. The problem with the threads is that they eat up a lot CPU. 

Now I'm lost. Yes, the app creates 25000 transaction per minute. Is this to much for DB2? I assumed that DB2 also reuses resources/threads. I actually have no idea what happens between the JDBC layer and the database on zOS. Has somebody a link that explains what happens in between? Or an idea what's going on there?

I got a call from the DB2 admin that my application creates a new connection for each transaction.

I checked the app running on Kubernetes using the latest JDBC driver jcc 11.5.9 that the connection pool is properly configured. Logging says yes, and also the metrics say yes. From the Java point of view everything looks ok. 70 JDBC connections and millions of usages.

The zOS admin says he sees millions of connections and even worse millions of threads. The problem with the threads is that they eat up a lot CPU. 

Now I'm lost. Yes, the app creates 25000 transaction per minute. Is this to much for DB2? I assumed that DB2 also reuses resources/threads. I actually have no idea what happens between the JDBC layer and the database on zOS. Has somebody a link that explains what happens in between? Or an idea what's going on there?

That's exactly what our admin said, but our debug logs log the creation of connections with object reference. And the logs tell a different story, last try I got 63 connection objects logged. And that's exactly what the metrics say. I had several code reviews and log analysis on the Java side that say everything is ok on Java side. How can I create millions of connections without anything being logged? Both the logs and the metrics tell the story that everything is fine, the count of usage, the count of connections allocated....
On Java side there are no errors. I use Spring repositorys with generated finder methods, no explicit cursor handling. There is a Hikari connection pool used which provides the metrics. All pretty standard which I used for several databases where I could see the DB side, there I could see the number of connections. I uses autoCommit default which is true.
For me it looks like the threads are not being reused. Since I don't have explicit cursors, are there implicit cursors used for queries? Are there any other situations where reusage is forbidden? How about prepared statements? Maybe the jcc jdbc driver requires something special? 

I got a call from the DB2 admin that my application creates a new connection for each transaction.

I checked the app running on Kubernetes using the latest JDBC driver jcc 11.5.9 that the connection pool is properly configured. Logging says yes, and also the metrics say yes. From the Java point of view everything looks ok. 70 JDBC connections and millions of usages.

The zOS admin says he sees millions of connections and even worse millions of threads. The problem with the threads is that they eat up a lot CPU. 

Now I'm lost. Yes, the app creates 25000 transaction per minute. Is this to much for DB2? I assumed that DB2 also reuses resources/threads. I actually have no idea what happens between the JDBC layer and the database on zOS. Has somebody a link that explains what happens in between? Or an idea what's going on there?

That's exactly what our admin said, but our debug logs log the creation of connections with object reference. And the logs tell a different story, last try I got 63 connection objects logged. And that's exactly what the metrics say. I had several code reviews and log analysis on the Java side that say everything is ok on Java side. How can I create millions of connections without anything being logged? Both the logs and the metrics tell the story that everything is fine, the count of usage, the count of connections allocated....
On Java side there are no errors. I use Spring repositorys with generated finder methods, no explicit cursor handling. There is a Hikari connection pool used which provides the metrics. All pretty standard which I used for several databases where I could see the DB side, there I could see the number of connections. I uses autoCommit default which is true.
For me it looks like the threads are not being reused. Since I don't have explicit cursors, are there implicit cursors used for queries? Are there any other situations where reusage is forbidden? How about prepared statements? Maybe the jcc jdbc driver requires something special? 

I got a call from the DB2 admin that my application creates a new connection for each transaction.

I checked the app running on Kubernetes using the latest JDBC driver jcc 11.5.9 that the connection pool is properly configured. Logging says yes, and also the metrics say yes. From the Java point of view everything looks ok. 70 JDBC connections and millions of usages.

The zOS admin says he sees millions of connections and even worse millions of threads. The problem with the threads is that they eat up a lot CPU. 

Now I'm lost. Yes, the app creates 25000 transaction per minute. Is this to much for DB2? I assumed that DB2 also reuses resources/threads. I actually have no idea what happens between the JDBC layer and the database on zOS. Has somebody a link that explains what happens in between? Or an idea what's going on there?

That's exactly what our admin said, but our debug logs log the creation of connections with object reference. And the logs tell a different story, last try I got 63 connection objects logged. And that's exactly what the metrics say. I had several code reviews and log analysis on the Java side that say everything is ok on Java side. How can I create millions of connections without anything being logged? Both the logs and the metrics tell the story that everything is fine, the count of usage, the count of connections allocated....
On Java side there are no errors. I use Spring repositorys with generated finder methods, no explicit cursor handling. There is a Hikari connection pool used which provides the metrics. All pretty standard which I used for several databases where I could see the DB side, there I could see the number of connections. I uses autoCommit default which is true.
For me it looks like the threads are not being reused. Since I don't have explicit cursors, are there implicit cursors used for queries? Are there any other situations where reusage is forbidden? How about prepared statements? Maybe the jcc jdbc driver requires something special? 

I got a call from the DB2 admin that my application creates a new connection for each transaction.

I checked the app running on Kubernetes using the latest JDBC driver jcc 11.5.9 that the connection pool is properly configured. Logging says yes, and also the metrics say yes. From the Java point of view everything looks ok. 70 JDBC connections and millions of usages.

The zOS admin says he sees millions of connections and even worse millions of threads. The problem with the threads is that they eat up a lot CPU. 

Now I'm lost. Yes, the app creates 25000 transaction per minute. Is this to much for DB2? I assumed that DB2 also reuses resources/threads. I actually have no idea what happens between the JDBC layer and the database on zOS. Has somebody a link that explains what happens in between? Or an idea what's going on there?

I got a call from the DB2 admin that my application creates a new connection for each transaction.

I checked the app running on Kubernetes using the latest JDBC driver jcc 11.5.9 that the connection pool is properly configured. Logging says yes, and also the metrics say yes. From the Java point of view everything looks ok. 70 JDBC connections and millions of usages.

The zOS admin says he sees millions of connections and even worse millions of threads. The problem with the threads is that they eat up a lot CPU. 

Now I'm lost. Yes, the app creates 25000 transaction per minute. Is this to much for DB2? I assumed that DB2 also reuses resources/threads. I actually have no idea what happens between the JDBC layer and the database on zOS. Has somebody a link that explains what happens in between? Or an idea what's going on there?