2

У нас есть приложение, использующее MySQL на Glassfish с использованием JPA (Hibernate), который работает нормально.Glassfish, PostgreSQL и закрытые соединения

Затем мы переключились на PostgreSQL, и почти все работает нормально. Единственная проблема, которая у нас есть, в том, что через некоторое время приложение перестает отвечать на запросы и выдает исключение, поскольку подключение к БД был закрыт:

[#|2012-06-19T21:51:22.050+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=38;_ThreadName=Thread-2;|4816089 [p: thread-pool-1; w: 21] WARN org.hibernate.util.JDBCExceptionReporter - SQL Error: 0, SQLState: 08006 
[#|2012-06-19T21:51:22.050+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=38;_ThreadName=Thread-2;|4816089 [p: thread-pool-1; w: 21] ERROR org.hibernate.util.JDBCExceptionReporter - An I/O error occured while sending to the backend. 
[#|2012-06-19T21:51:22.052+0200|SEVERE|glassfish3.1.2|javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource|_ThreadID=38;_ThreadName=Thread-2;|RAR5031:System Exception 
javax.resource.spi.LocalTransactionException: This connection has been closed. 
     at com.sun.gjc.spi.LocalTransactionImpl.rollback(LocalTransactionImpl.java:134) 
     at com.sun.enterprise.resource.ConnectorXAResource.rollback(ConnectorXAResource.java:213) 
     at com.sun.enterprise.transaction.JavaEETransactionImpl.rollback(JavaEETransactionImpl.java:571) 
     at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.rollback(JavaEETransactionManagerSimplified.java:893) 
     at com.sun.enterprise.transaction.UserTransactionImpl.rollback(UserTransactionImpl.java:234) 
     at ch.ethz.id.wai.lakshmi.engine.common.TransactionHelper.rollbackTransaction(TransactionHelper.java:43) 
     at ch.ethz.id.wai.lakshmi.stdcmp.tracking.StandardTracking.updateStatus(StandardTracking.java:50) 
     at ch.ethz.id.wai.lakshmi.engine.ejb.LakshmiServerBean.updateTrackingStatus(LakshmiServerBean.java:992) 
     at ch.ethz.id.wai.lakshmi.engine.ejb.LakshmiServerBean.executeNextWorkflowStep(LakshmiServerBean.java:771) 
     at ch.ethz.id.wai.lakshmi.engine.ejb.LakshmiServerBean.executeNextWorkflowStep(LakshmiServerBean.java:683) 
     at ch.ethz.id.wai.lakshmi.engine.ejb.LakshmiServerBean.continueWorkflow(LakshmiServerBean.java:602) 
     at ch.ethz.id.wai.lakshmi.engine.ejb.LakshmiServerBean.processSubmitOrderRequest(LakshmiServerBean.java:487) 
     at ch.ethz.id.wai.lakshmi.engine.ejb.LakshmiServerBean.onMessage(LakshmiServerBean.java:360) 
     at sun.reflect.GeneratedMethodAccessor133.invoke(Unknown Source) 
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
     at java.lang.reflect.Method.invoke(Method.java:597) 
     at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052) 
     at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124) 
     at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4180) 
     at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5368) 
     at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348) 
     at com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1099) 
     at com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:81) 
     at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:171) 
     at $Proxy264.onMessage(Unknown Source) 
     at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:260) 
     at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:114) 
     at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497) 
     at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540) 
Caused by: org.postgresql.util.PSQLException: This connection has been closed. 
     at org.postgresql.jdbc2.AbstractJdbc2Connection.checkClosed(AbstractJdbc2Connection.java:714) 
     at org.postgresql.jdbc2.AbstractJdbc2Connection.rollback(AbstractJdbc2Connection.java:731) 
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
     at java.lang.reflect.Method.invoke(Method.java:597) 
     at org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$ConnectionHandler.invoke(AbstractJdbc23PooledConnection.java:352) 
     at java.lang.reflect.Method.invoke(Method.java:597) 
     at org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$ConnectionHandler.invoke(AbstractJdbc23PooledConnection.java:352) 
     at $Proxy161.rollback(Unknown Source) 
     at com.sun.gjc.spi.LocalTransactionImpl.rollback(LocalTransactionImpl.java:128) 
     ... 28 more 

Мы создаем пулы соединений таким же образом для MySQL и PostgreSQL:

asadmin create-jdbc-connection-pool \ 
    --restype javax.sql.DataSource \ 
    --datasourceclassname org.postgresql.jdbc2.optional.PoolingDataSource \ 
    --property URL='jdbc:postgresql://127.0.0.1:5432/doi':serverName=localhost:databaseName=doi:user=doi:password=******** doi 

и

asadmin create-jdbc-connection-pool \ 
    --restype javax.sql.DataSource \ 
    --datasourceclassname com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource \ 
    --property serverName=127.0.0.1:dataBaseName=doi:user=doi:********=doi:schema=doi doi 

Как настроить пул данных, чтобы закрыть незанятое соединение или держать их в живых и избежать закрытой ошибки соединения?

+0

(непроверенный) может быть добавлен tcpKeepAlive = true к строке подключения jdbc –

+0

Я попытаюсь, но на самом деле пул соединений должен иметь возможность управлять соединениями, не сохраняя их всегда живыми – Matteo

+0

Этот вопрос кажется удивительно похожим: http: // stackoverflow.com/questions/11417504/in-multi-server-environment-if-site-has-inactivity-for-more-than-15-minutes-se –

ответ

2

Pg соединения должны оставаться в силе на неопределенный срок, пока:

  • Сервер БД не остановлена ​​или перезапуске
  • IP сервер БД не меняется
  • Там нет никакой связи отслеживания или NAT маршрутизатор между клиентом и сервером

Последние две проблемы не являются проблемой, поскольку вы подключаетесь к локальному хосту, поэтому вам не нужны какие-либо специальные меры для поддержания ваших соединений ali ве.

Я немного подозрительно, что вы используете org.postgresql.ds.PGSimpleDataSource. У Glassfish есть собственный пул, и вы, вероятно, должны использовать план org.postgresql.datasource.Datasource. Вероятно, у вас есть два уровня объединения, которые могут быть запутаны. Вы отметите заявление в the PgJDBC documentation, что:

Реализация данных источника пулы, представленная здесь, не является самым навороченный в мире. Между прочим, соединения никогда не закрываются до тех пор, пока сам пул не будет закрыт; нет возможности сжать бассейн . Кроме того, соединения, запрошенные для пользователей, отличных от настроенного пользователя по умолчанию , не объединены. Его обработка ошибок иногда не может удалить сломанное соединение из пула. В общем случае не рекомендуется использовать пул соединений PostgreSQL ™. Проверьте ваш сервер приложений или ознакомьтесь с отличным центом jakarta Проект DBCP.

Пожалуйста, переключитесь на использование org.postgresql.ds.PGSimpleDataSource и убедитесь, что это устраняет проблемы.

+0

На самом деле я использовал 'org.postgresql.ds.PGPoolingDataSource'. Я попробую с 'org.postgresql.datasource.Datasource'. – Matteo

+0

С PGSimpleDataSource он работает как шарм. Спасибо – Matteo

+0

@Matteo Спасибо, что вернулись и подтвердили это. Рад помочь. –

Смежные вопросы