JDBC driver - Statement.setQueryTimeout not working

I've created an executable Jar file instantiating the 2023-10 version of the INFOR JDBC driver.

My team members can either submit a single SQL file or a directory of SQL files to execute.

We occasionally have a glitch where a two-minute query will hang for an hour. The only way for me to kill the process is to log onto the server, find the PID of the java and kill it, not a good solution.

I would like to set the timeout out of 5 minutes on the statement and not the connection as I may execute 1 or many SQL files, I want to reuse the connection between statements.

It doesn't seem the standard timeout works with your driver as I've set the "Statement.setQueryTimeout" at 30 seconds (for testing purposes) for queries taking 45 to 90 seconds. In each case the SQLTimeoutException or a SQLException is never thrown.

Is there something in the below code I need to change to correctly interact with your driver?

Thank you.

Find more posts tagged with

Infor Data Fabric

Accepted answers

All comments

robert-nevinger

Datalake is based on AWS S3. Datalake documents are stored as Infrequent Access Object Storage Class. A Compass query must convert a document from Infrequent Storage Class to Frequent Storage Class before you see query results, this is the latency experienced at the console. The Compass JDBC driver would have at least a 2 step Datalake API to produce query results. I deploy a jar through AWS lambda and have not yet experienced a hung PID, but I also haven't gone after large datasets or complex joins. I have no way to confirm if the object class conversion is the culprit, Infor would have to trace it.

unknown

Hey @keith-lofy ,

Pretty interesting background and request. Want to add some detail to help qualify what you're most likely experiencing. When issuing a query, Compass SQL checks for any new data objects in storage since the last time a client has requested data from a given "table" and subsequently caches the data before your query starts processing. Often, users might experience a case where running a query takes longer the first time and is relatively zippy when immediately run again.

It's unlikely that the query timed out on the Compass SQL side but was still pre-processing some data. It also may be the case that the setQueryTimeout would only take effect once the query was actually processing rows of data but it may have been that you already killed the process request from your client side.

Clients can cancel the query using the JDBC protocol or the /cancel API (documentation). We do have a platform update to Compass SQL that will largely eliminate the felt presence of this caching operation coming quite soon and is in Early Access testing today. In any case, Compass SQL can potentially process extremely large workloads that take a long time. It sounds like your query profiles and workloads are more aligned with small data look-ups and retrieval or ad-hoc usage. Is that fair?

Given your work in the JDBC implementation, you can check the Javadocs under the Utilities menu for more information on the classes.

Feel free to reach out to me via message - I'm interested to hear more about your use cases and usage here and see what our roadmap looks like in terms of how you use the platform.

unknown

Mike,
Thank you for the responce, I'll reach out to you directly.

I'll modify my code to wrap the call in a timer class so I can elegantly exit the call.

Copyright © 2025 Infor. All rights reserved.