An exception is thrown at Jdbctemplate.update (unique key violation).
After certain number of these exceptions the hikaripool gets timed out with connection not available (Checked and found out that this error occurs due to pool overload)
Can too many sql exceptions cause a hikariCP timeout?
Related
In one of spring boot microservice app, i was having problem with connection leakage. Some of the connection were not being returned to the Pool and i was using only default configuration for Hikari. Now I put a leakDetectionThreshold and it starts explicitly taking back connections and returning it to the Pool. My question is related to these broken connections, even though as per the specification of Hikari pool, if a connection retuned to pool in a broken state, Pool handlers would rollback the transactions so thay It didn't bleed out for the next consumer. But in my case, transactions were not rolled back. What is happening here?
I have spring batch which reads from ActiveMQ Artemis and write to Oracle database. Now I want to implement a mechanism to cater if any SQLException occured in JDBC batch write like following,
org.springframework.jdbc.UncategorizedSQLException: PreparedStatementCallback; uncategorized SQLException for SQL
I tried with SkipPolicy and CompositeStepExecutionListener but it seems methods not get called on error. My target is to write the error prone message to a error queue or logs. Is there a way I can do it without extending JdbcBatchItemWriter. Also I want to know your opinion on whether my error handing is efficient?
My target is to write the error prone message to a error queue or logs
ItemWriteListener#onWriteError should be called on write failures. It gives you access to the items of the failed chunk as well as the exception that caused the failure. You can implement this listener and send failed items to your error queue or log them as needed.
When a spring boot request starts, it obtains a connection from the pool. My question is - is this connection remains tied to the request thread (even if it is not executing any query) and only returned to the pool when request completes?
For example, if I'm doing something like:
Request starts
Execute a query (20ms)
Call external http service (1500ms)
Request completes
Would the connection obtained by this request thread remain occupied with the thread (and not available to other requests) for 20ms or 1520ms?
PS: I'm using Spring Boot 2.0 with HikariCP and I'm not using #Transactional.
Thanks.
If you have Spring MVC on your classpath, Spring will configure an instance of OpenEntityManagerInViewInterceptor automatically (in org.springframework.boot.autoconfigure.orm.jpa.JpaBaseConfiguration.JpaWebConfiguration), unless you configure spring.jpa.open-in-view to false. This interceptor will open an instance of EntityManager and bind it to the TransactionSynchronizationManager for the whole duration of the request.
What that means is that at the first use of a repository query, it will borrow a connection from the pool and keep it until the end of the request when the EntityManager is closed by the interceptor. It's the EntityManager's responsibility to return the connection to the pool. So, in that case, the connection will be borrowed for 1520ms in your example.
If you disable the spring.jpa.open-in-view option, a connection will be borrowed and returned at each use of a repository query given you don't use any explicit transaction. While this may look better, you have to keep in mind that managed instances of your entities will need to be reattached systematically on each persist operation so it may be costly. You will also loose the benefits of the EntityManager caching. To avoid this, use transactions to read/modify/persist your entities and avoid reattaching.
Finally, keep in mind that if you disable spring.jpa.open-in-view, since you don't have an EntityManager around for the duration of the request, you will need to make sure your lazy loaded relations are loaded inside a transaction otherwise you'll get the dreaded LazyInitializationException.
Basically it depends,
If you close conection it will be release back to pool and will be ready soon according to configuration (below) so it will be ~20ms (+ time to get back to pool)
If you don't close the connection it will wait until the configuration allow it, if it allow indefinite time, theoretically it can be causing a leak in your application and not return to pool until apllication is shutdown.
See answer about Hikari handling returning connections to pool:
The Hikari housekeeper runs every 30s, which closes any connections that are not in use and are older than maxLifetime. If there are more than minimumIdle number of connections the housekeeper will close connections that have been idle for longer than idleTimeout.
See more about max life time of connection:
by default Oracle does not enforce a max lifetime for connections (neither on JDBC driver side (1), nor on server side(2)). So in this respect, the "infrastructure-imposed connection time limit" is +infinity
I am working on a project which makes extensive use of spring transactions. I t so happened that i was throwing an exception AND NOT HANDLING IT PROPERLY which does not commit or rollback the transact Ion. So the connection remains active even when the thread is stopped. When new request to the web server ( Apache tomcat 7.0) comes the spring provides the earlier connection to the new thread. Since the thread didn't started the connection so the thread couldn't close it either ie .commit doesn't work. because of which the objects are not getting persisted in database in the consequent transactions even when there is no exception. How can i work around the problem so that i can detect where is the actual problem happening or can a design an exit point where i can explicitly close the transaction before response is sent to browser.
A runtime unchecked exception or error that is thrown from a #Transactional method will rollback that transaction by default; a return or a checked exception will commit the transaction by default. You can tell Spring to override that behaviour using the annotation type elements of the #Transactional annotation.
The Spring Framework reference manual has an entire chapter devoted to transaction management. You need to read and understand that as your starting point.
Our application uses WAS SIB for JMS implementation and while posting to a queue on WAS 8.5, getting following exception
javax.jms.JMSException: CWSIA0067E: An exception was received during the call to the method JmsMsgProducerImpl.: com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0047E: An operation was attempted on a connection that is already closed..
at com.ibm.ws.sib.api.jms.impl.JmsMsgProducerImpl.(JmsMsgProducerImpl.java:456)
at com.ibm.ws.sib.api.jms.impl.JmsQueueSenderImpl.(JmsQueueSenderImpl.java:60)
at com.ibm.ws.sib.api.jms.impl.JmsQueueSessionImpl.instantiateProducer(JmsQueueSessionImpl.java:224)
We face the same issue.
Assumption: You are holding a connection longer than you should. In our case I suspect the persistent messaging as cause. If the underlying DB connection is dropped and you hold the JMS connection longer then this error appears.