LockOtimista JPA Pool Conexões

Tenho uma aplicação que utilizo pool de conexões sempre funcionou de boa.
Mas agora apos 6 meses eu constatei um bug que sempre ocorreu. Queria uma ajuda de vocês. Estou utilizando pool com C3P0.

Exemplo: estou editando um mesmo objeto em duas sessões diferentes.
Ao salvar o objeto nas duas sessões, a primeira sessão ele persiste e na segunda sessão da uma mensagem do look otimista. ate ai blz. Esta fazendo de acordo.

Porem ele gera um erro no log, que comecei a ver após ativar essa opção “debugUnreturnedConnectionStackTraces” no pool.

O erro e o que segue:

2016-10-19 16:56:47 INFO BasicResourcePool:1544 - A checked-out resource is overdue, and will be destroyed: com.mchange.v2.c3p0.impl.NewPooledConnection@32abd809 2016-10-19 16:56:47 INFO BasicResourcePool:1547 - Logging the stack trace by which the overdue resource was checked-out. java.lang.Exception: DEBUG STACK TRACE: Overdue resource check-out stack trace. at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:588) at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutAndMarkConnectionInUse(C3P0PooledConnectionPool.java:758) at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:685) at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:140) at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:139) at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:380) at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:228) at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:171) at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doBegin(JdbcTransaction.java:67) 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) at br.com.controlesolicitacoes.dao.PrioridadeDAO.gravar(PrioridadeDAO.java:28) at br.com.controlesolicitacoes.controle.PrioridadeControle.gravar(PrioridadeControle.java:33) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.el.parser.AstValue.invoke(AstValue.java:247) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:267) at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) at javax.faces.component.UICommand.broadcast(UICommand.java:315) at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282) at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:100) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at br.com.controlesolicitacoes.filtropagina.FiltroPrivado.doFilter(FiltroPrivado.java:49) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

Ali ele diz que uma conexão do banco não retornou ao pool, mas eu fecho o EM no finally do DAO. mas ele por algum motivo não respeita isso. E o que ocorre é que esta matando as conexões do banco. Se eu edito e salvo registros normais sem esse erro do look otimista, funciona de boa, sem problemas. Alguma ideia?

e executando em debug, viu já ?

Sugiro editar o título do post
Look = Aparência
Lock = Bloqueio

Ha quem interessar, descobri meu problema.
Como não utilizo CDI e controlo as transações na mão.

Quando ocorria a Exception OptimisticLockException por causa do @Version da entidade. A em não fazia o Rollback da transação e e ficava a transação aberta no banco.
Dai tive que fazer na mão
em.getTransaction().rollback();
finalizado

1 curtida