Hi Renan,

This could be due to database-side blocking or a hanging query. When this situation occurs, it would be good to check the database at that time to see if the session ended up in a deadlock scenario or long table locks. Another possible reason could be stale connections.

To help mitigate this, you can configure the connection timeout and read timeout properties. For stale connections, consider setting appropriate block and expire timeout values as well.

Regards,
Satish

Dear Satish!

Thank you very much for your response! Next time this happens, I'll check with the destination system DBA .

Regarding the connection timeout and read timeout properties, the connection that had this issue recently has the following connection properties:

Reading the documentation on Configuring Adapter for JDBC Connections - IBM Documentation,

I still couldn't understand if the above configuration is the cause of the failing.

Or must I set the connection timeout and read timeout properties in another place? Such as the  "Settings > Extended" page?

Thanks again!

Dear Satish!

Thank you very much for your response! Next time this happens, I'll check with the destination system DBA .

Regarding the connection timeout and read timeout properties, the connection that had this issue recently has the following connection properties:

Reading the documentation on Configuring Adapter for JDBC Connections - IBM Documentation,

I still couldn't understand if the above configuration is the cause of the failing.

Or must I set the connection timeout and read timeout properties in another place? Such as the  "Settings > Extended" page?

Thanks again!

Hi Renan,

This could be due to database-side blocking or a hanging query. When this situation occurs, it would be good to check the database at that time to see if the session ended up in a deadlock scenario or long table locks. Another possible reason could be stale connections.

To help mitigate this, you can configure the connection timeout and read timeout properties. For stale connections, consider setting appropriate block and expire timeout values as well.

Regards,
Satish

If the issue is isolated to a single adapter service using the connection then I would recommend setting the query timeout at adapter service level, if you using standard adapter service templates (excluding stored proc calls). For other templates you can set the timeout at service level while invoking from a parent service.

This will only avoid the hanging thread issue but will not resolve what is causing the actual query to take that long. You will have to work with your DBA to run a profiler to understand where the blocking is happening.

Dear Akshith,

Thank you for your suggestions. We're now going to aim to always stalish a query timeout. We usually set -1 for all adapter services, but after this type of issue we won't do that anymore.

If this kind of issue happens again, is there any other way to cut the connection on I.S? I mean, can we drop this transaction/connection from our side without depending on a DBA to do that?

I remember that the last time I requested a DBA to check the sessions/transactions related with our I.S and drop them, he said there were no connections and he couldn't drop anything.

Thanks again!

If the issue is isolated to a single adapter service using the connection then I would recommend setting the query timeout at adapter service level, if you using standard adapter service templates (excluding stored proc calls). For other templates you can set the timeout at service level while invoking from a parent service.

This will only avoid the hanging thread issue but will not resolve what is causing the actual query to take that long. You will have to work with your DBA to run a profiler to understand where the blocking is happening.

Dear Venkateshan Manickam,

Thank you for all information you added and sorry for my late response.

I understand that we can se the timeout properties in the connection properties. I  think we're going to apply on all of them with a timeout limit of 1 hour, just to ensure that the flow service can be executed normally next time.

When you say to reload the user package, you mean to reload the package that contains the JDBC Adapter Service?

Thanks again!

Dear Venkateshan Manickam,

Thank you for all information you added and sorry for my late response.

I understand that we can se the timeout properties in the connection properties. I  think we're going to apply on all of them with a timeout limit of 1 hour, just to ensure that the flow service can be executed normally next time.

When you say to reload the user package, you mean to reload the package that contains the JDBC Adapter Service?

Thanks again!

------------------------------
Renan Kaic Lopes
------------------------------

Dear Christoph,

Please, do you have any other suggestion so we can find an workaround for this problem?

It's been impacting us for some months. It happens suddenly and then we have to restart our IS in order to fix it.

Last time this happened it was in a Saturday evening, and the responsible DBA wasn't available to check the DB sessions, transactions, etc. and we had to restart the IS again.

Thank you in advance!

------------------------------
Renan Kaic Lopes
------------------------------


Original Message:
Sent: Tue June 02, 2026 10:05 AM
From: Christoph Jahn
Subject: Can't disable JDBC adapter connection

You can of course increase the timeout like this. But the chances that
it will help are extremely small.

As Venkateshan wrote (and I as well) the symptoms point to killed socket
connection. Changing a timeout will have zero effect in this case.



Original Message:
Sent: 6/2/2026 9:56:00 AM
From: Renan Kaic Lopes
Subject: RE: Can't disable JDBC adapter connection

Dear Venkateshan Manickam,

Thank you for all information you added and sorry for my late response.

I understand that we can se the timeout properties in the connection properties. I  think we're going to apply on all of them with a timeout limit of 1 hour, just to ensure that the flow service can be executed normally next time.

When you say to reload the user package, you mean to reload the package that contains the JDBC Adapter Service?

Thanks again!

------------------------------
Renan Kaic Lopes
------------------------------

Dear Venkateshan Manickam,

Thank you for all information you added and sorry for my late response.

I understand that we can se the timeout properties in the connection properties. I  think we're going to apply on all of them with a timeout limit of 1 hour, just to ensure that the flow service can be executed normally next time.

When you say to reload the user package, you mean to reload the package that contains the JDBC Adapter Service?

Thanks again!

Hi Renan,

  This looks like a dead TCP socket rather than a DB or timeout issue. A firewall between IS and the DB is probably dropping idle connections silently, so the pool still thinks they're good. When one of those gets used, the driver does a socket read that never returns and the thread sits in a native read forever.

  That's why the rest fails too - Disable waits for that connection to come back (it never does), and kill-thread sends a Java interrupt, which can't break a blocking socket read. So only a restart clears it. If you want to confirm, take a thread dump while it's hung and you'll see SocketInputStream.socketRead0 ... oracle.net...

  The timeout ideas won't help here: query timeout fires Statement.cancel(), which goes over the same dead socket and hangs too, and login/connection timeout only covers connecting. Neither touches the socket layer.

  What fixes it is a socket-level timeout. Cleanest is to set Network Timeout (msec) on the JDBC connection - try 120000, kept above your longest query. That maps to setNetworkTimeout() and can actually break a stuck read. If that field isn't there, add a driver  property in Other Properties instead: Oracle thin → oracle.jdbc.ReadTimeout=120000, oracle.net.CONNECT_TIMEOUT=10000,
  oracle.net.keepAlive=true; DataDirect (jdbc:wm:oracle://) → NetworkTimeout=120 (sec). The oracle.* ones don't apply to DataDirect, so check your data source class first.

  I'd also lower OS tcp_keepalive_time below the firewall's idle timeout and turn on a pool validation query. But the real fix is getting that firewall idle timeout raised/disabled on the IS↔DB path - the rest is a safety net.

  One heads-up: this is preventive. It stops new hangs but won't unfreeze one that's already stuck - for that, reload the package owning the connection to clear the pool without a full restart.

  Hope that helps.

Dear Venkateshan Manickam,

Thank you for all information you added and sorry for my late response.

I understand that we can se the timeout properties in the connection properties. I  think we're going to apply on all of them with a timeout limit of 1 hour, just to ensure that the flow service can be executed normally next time.

When you say to reload the user package, you mean to reload the package that contains the JDBC Adapter Service?

Thanks again!