Oracle Listener продолжает падать и перестает отвечать на запросы

У нас есть спокойный веб-сервис, который использует спящий режим и Glassfish для доступа к базе данных Oracle. Однако после нескольких простых транзакций (несколько простых запросов и получение некоторых данных) прослушиватель Oracle перестает отвечать на запросы со следующей ошибкой:

ORA-12519, TNS:no appropriate service handler found
org.hibernate.exception.GenericJDBCException: Cannot open connection
at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:91)
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:79)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:363)
at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:122)
at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:125)
at org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:57)
at org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1308)
at data.CommonUnitOfWork.<init>(CommonUnitOfWork.java:29)
at data.UnitOfWorkFactory.createCommonUnitOfWork(UnitOfWorkFactory.java:14)
at controller.UserController.getUser(UserController.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:708)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:722)


Caused by: java.sql.SQLException: Listener refused the connection with the following error:
ORA-12519, TNS:no appropriate service handler found
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:113)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:263)
at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:389)
at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:454)
at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:165)
at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:35)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:802)
at java.sql.DriverManager.getConnection(DriverManager.java:579)
at java.sql.DriverManager.getConnection(DriverManager.java:190)
at org.hibernate.connection.DriverManagerConnectionProvider.getConnection(DriverManagerConnectionProvider.java:110)
at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:360)
... 51 more

И единственное решение, позволяющее снова запустить службу, — это перезапустить Listener.

Спасибо за вашу помощь заранее.

РЕДАКТИРОВАТЬ: Версия Oracle — 11g, веб-служба для отдыха — в java. Слушатель перестает отвечать после нескольких минут работы, состоящей из выполнения небольшого количества запросов (например, 4 или 5) для извлечения менее 5 строк таблицы в базе данных (которая состоит примерно из 10 столбцов); работа совсем не тяжелая. База данных состоит примерно из 20 таблиц. В некоторых запросах соединения выполняются с использованием критериев спящего режима между 2 или 3 таблицами, что не так уж сложно и не должно рассматриваться как «тяжелая нагрузка».

РЕДАКТИРОВАТЬ 2: модель использует какой-то тип UnitOfWorkFactory для реализации шаблона репозитория. Для каждого запроса (например, создание нового объекта, редактирование существующего объекта или поиск) модель создает unitOfWork, в котором будет создаваться спящий сеанс, выполнять задание и затем закрывать сеанс.


person Pejman    schedule 22.04.2013    source источник
comment
В вашем описании отсутствуют некоторые важные детали, такие как версия Oracle, платформа, используемый пул соединений jdbc, частота подключения, тип выполняемой работы, небольшие поиски, длительные операции?   -  person ik_zelf    schedule 22.04.2013
comment
@ik_zelf спасибо за ваш ответ, я добавил некоторые детали в сообщение. Не могли бы вы сказать мне, что вы имеете в виду под используемым пулом соединений jdbc?   -  person Pejman    schedule 22.04.2013
comment
Создает ли каждое действие новый сеанс или сеансы доступны из пула соединений? (подключения серьезно снижают производительность и должны быть максимально предотвращены) Слушатель обычно помогает создать сеанс. Этот сеанс следует использовать повторно, определив пул соединений в Glassfish для вашего приложения.   -  person ik_zelf    schedule 22.04.2013
comment
хм... может быть, проблема в этом, потому что, как я уже упоминал выше (см. Редактировать 2 в моем посте), модель создает новый сеанс для каждой работы, а затем закрывает сеанс. Это решение было принято из соображений безопасности и риска сохранения сеанса связи с базой данных открытым.   -  person Pejman    schedule 22.04.2013
comment
Это один из лучших способов создать плохо работающее приложение, которое очень чувствительно к сбоям, вызванным его дизайном. Используйте пул соединений.   -  person ik_zelf    schedule 22.04.2013
comment
Подойдет :) Большое спасибо :) не могли бы вы указать мне правильное направление? С чего начать, чтобы использовать пул соединений?   -  person Pejman    schedule 22.04.2013


Ответы (1)


Обязательно используйте пул соединений. Это предотвращает множество ненужных и очень дорогих повторных подключений к базе данных. Например, проверьте здесь и перейдите на страницу вниз, чтобы "Сначала создать Пул соединений JDBC" Создание соединений с базой данных — очень трудоемкая задача, которая значительно снижает общую производительность вашей системы. Это потому, что это процесс сериализации.

Используя пул соединений, вы гарантируете, что для вашего приложения всегда будут доступны сеансы, даже если сам прослушиватель не работает в течение короткого периода времени.

person ik_zelf    schedule 22.04.2013