Postgres соединение было закрыто ошибка в Spring Boot
Я запускаю приложение Spring Boot для создания REST API. Часто я получаю сообщение о том, что соединение с базой данных закрыто, и после этого я не могу делать какие-либо вызовы приложению. Я использую Postgres DB. Это полная трассировка стека:
org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction; nested exception is javax.persistence.PersistenceException: org.hibernate.TransactionException: JDBC begin transaction failed:
at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:431)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:373)
at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:457)
at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:276)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207)
at com.sun.proxy.$Proxy91.findByUriMoniker(Unknown Source)
at com.mypkg.businessobjects.OrderInfoBO.getOrderInfo(OrderInfoBO.java:76)
at com.mypkg.controller.OrderInfoController.getOrderInfo(OrderInfoController.java:78)
at sun.reflect.GeneratedMethodAccessor104.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)
at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:137)
at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:110)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandleMethod(RequestMappingHandlerAdapter.java:777)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:706)
at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:943)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:877)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:966)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:857)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:842)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
at com.mypkg.config.CORSFilter.doFilter(CORSFilter.java:39)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.persistence.PersistenceException: org.hibernate.TransactionException: JDBC begin transaction failed:
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:1771)
at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:64)
at org.springframework.orm.jpa.vendor.HibernateJpaDialect.beginTransaction(HibernateJpaDialect.java:159)
at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:380)
... 56 more
Caused by: org.hibernate.TransactionException: JDBC begin transaction failed:
at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doBegin(JdbcTransaction.java:76)
at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin(AbstractTransactionImpl.java:162)
at org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1435)
at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:61)
... 58 more
Caused by: org.postgresql.util.PSQLException: This connection has been closed.
at org.postgresql.jdbc2.AbstractJdbc2Connection.checkClosed(AbstractJdbc2Connection.java:833)
at org.postgresql.jdbc2.AbstractJdbc2Connection.getAutoCommit(AbstractJdbc2Connection.java:794)
at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.apache.tomcat.jdbc.pool.ProxyConnection.invoke(ProxyConnection.java:126)
at org.apache.tomcat.jdbc.pool.JdbcInterceptor.invoke(JdbcInterceptor.java:108)
at org.apache.tomcat.jdbc.pool.DisposableConnectionFacade.invoke(DisposableConnectionFacade.java:81)
at com.sun.proxy.$Proxy56.getAutoCommit(Unknown Source)
at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doBegin(JdbcTransaction.java:68)
... 61 more
Когда я перезапускаю приложение, оно уходит. Я думаю, что эта проблема возникает, когда я перезагружаю свою базу данных postgres. Почему это происходит?
6 ответов
Очень актуальный вопрос и с этой проблемой обычно сталкиваются многие. Исключение обычно возникает, когда сетевое соединение теряется между пулом и базой данных (большую часть времени из-за перезапуска). Глядя на указанную вами трассировку стека, становится ясно, что вы используете jdbc pool чтобы получить связь. JDBC pool имеет опции для тонкой настройки различных настроек пула соединений и записи подробностей о том, что происходит внутри пула.
Вы можете обратиться к подробной документации Apache по конфигурации пула, чтобы указать время ожидания отмены
Проверьте параметры removeAbandoned, removeAbandonedTimeout, logAbandoned
Кроме того, вы можете использовать дополнительные свойства для дальнейшего ужесточения проверки
Используйте testXXX и validationQuery для проверки правильности подключения.
Это наполовину ответил другие посты, и я хотел быть очень откровенным. Также я хотел быть более Spring-Boot-esque. Не стесняйтесь изменять интервалы времени по мере необходимости.
Вариант 1: выбросить разорванные соединения из пула.
Используйте эти свойства:
spring.datasource.test-on-borrow=true
spring.datasource.validation-query=SELECT 1;
spring.datasource.validation-interval=30000
Вариант 2: поддерживать соединения в пуле живыми.
Используйте эти свойства:
spring.datasource.test-while-idle=true
spring.datasource.validation-query=SELECT 1;
spring.datasource.time-between-eviction-runs-millis=60000
Вариант 3: заблаговременно выбрасывать незанятые соединения.
Используйте эти свойства (Примечание. Мне не удалось найти надежную документацию по этому вопросу для Spring Boot. Кроме того, время ожидания указывается в секундах, а не в миллисекундах):
spring.datasource.remove-abandoned=true
spring.datasource.remove-abandoned-timeout=60
Удачной загрузки!
Это исключение в основном говорит о том, что соединение JDBC было закрыто, но это не означает, что сервер базы данных не работает (для этого есть еще одно исключение). Это могло произойти при перезапуске сервера БД или после того, как сервер БД разорвал соединение (например, из-за тайм-аута). Возникает вопрос, почему приложение не подключается к серверу повторно по новому HTTP-запросу.
Обычно это неправильная конфигурация пула соединений, который должен проверять соединение каждый раз, когда приложение "заимствует" его. Все, что вам нужно для решения этой проблемы, это следующее:
spring.datasource.validation-query=SELECT 1;
spring.datasource.test-on-borrow=true
Другие параметры конфигурации (из других ответов) - это оптимизации, которые не являются строго обязательными для этого исключения.
Но иногда, даже если пул JDBC настроен правильно, может быть определенная ошибка приложения, при которой приложение удерживает соединение с БД, не возвращая его в пул JDBC после завершения HTTP-запроса. Таким образом, пул JDBC даже не имеет возможности проверить соединение с БД (все, что он знает, это то, что соединение с БД "РАЗРЕШЕНО"). Общее решение здесь - убедиться, что приложение возвращает соединение и "заимствует" новое соединение для каждого HTTP-запроса.
Один из примеров такой ошибки:
@Component
public MyService {
@Resource
private EntityManagerFactory emf;
private EntityManager em;
public MyService() {
em = emf.createEntityManager();//em never return back its JDBC connection to the pool (using em.close())
}
}
Решением указанной выше ошибки является использование внедренного / управляемого EntityManager (предпочтительно).
@Component
public MyService {
@PersistenceContext
private EntityManager em;
}
или если вам действительно нужно управлять им самостоятельно, создайте EntityManager для каждого HTTP-запроса и закройте его в блоке try-finally, если вы действительно
@Component
public MyService {
@Resource
private EntityManagerFactory emf;
private EntityManager em;
public void myMethod() {
EntityManager em = emf.createEntityManager();
try {
} finaly {
em.close();//do not forget other cleanup operations like rolling back the transaction
}
}
}
У меня была точно такая же проблема, с этой настройкой, также используя DataSource от Tomcat (org.apache.tomcat.jdbc.pool) для подключения к Heroku Postgres:
org.springframework.transaction.CannotCreateTransactionException:
Could not open JPA EntityManager for transaction
org.hibernate.TransactionException: JDBC begin transaction failed: ]
with root cause
org.postgresql.util.PSQLException: This connection has been closed.
Для меня это решило добавление кода инициализации DataSource (заимствование из вопроса Grails):
dataSource.setTestOnBorrow(true);
dataSource.setTestWhileIdle(true);
dataSource.setTestOnReturn(true);
dataSource.setValidationQuery("SELECT 1");
Я не уверен, что все эти три необходимы для установления стабильного соединения - возможно, нет - но включение всех, вероятно, не повредит.
JavaDocs разъясняет, что происходит: см., Например, setTestOnBorrow(), Возможно, немного удивительно, что по умолчанию такие тесты не проводятся.
У меня была точно такая же проблема, но в моем случае вышеупомянутые ответы не помогли. Я понял, что при выполнении длинного запроса появляется та же ошибка. В моем случае я вызвал findAll(итерируемые идентификаторы) и передал огромный список из более чем 100 000 идентификаторов. Разделение списка (например, использование ListUtils из Apache Commons или Google Guava) и вызов findAll() с меньшим количеством идентификаторов сделали свое дело.
когда вы пишете запросы в репозиторий, старайтесь сохранить аннотацию @Component там, в репозитории