Problema con Hibernate

por cierto a veces sale y a veces no, es decir: ejecuto una vez y todo parece estar ok, pero conforme sigo utilizando la aplicacion truena (haciendo la misma consulta)

Y ya le hiciste caso al stack trace, invocaste nextException para ver qué onda?

Eso de "A PooledConnection that has already signalled a Connection error is still in use!" lo he visto en ocasiones cuando ocurre un error ejecutando algo con una transacción abierta y que no se cacha la excepción para darle rollback, entonces se queda a la mitad y aunque se regrese la conexión al pool, está inutilizable. Algunos pools (como el de JBoss) detectan eso y arrojan una advertencia en log y destruyen la conexión, otros no lo detectan.

La sentencia que estás ejecutando es un UPDATE; si es parte de una transacción, tu problema podría ser un deadlock en la base de datos (ya sabes, una transacción bloquea un registro y luego quiere leer otro mientras que otra transacción tiene bloqueado ese segundo registro y está esperando a leer el registro que la primera transacción tiene bloqueado). Si no hay nada de eso, pues tal vez una bronca con el driver de PostgreSQL? deberías estar usando el 8.4-702 que es el adecuado para la versión que PostgreSQL que mencionas.

Si estás usando Spring o algo similar, configura un contexto para pruebas unitarias donde uses tu DataSource de c3p0 para ejecutar las mismas operaciones pero por fuera de un contenedor JEE, a ver si se puede reproducir el error. Otra opción es que pruebes con BoneCP o Apache DBCP a ver si la bronca está en c3p0... yo cuando uso Hibernate normalmente sólo le paso la referencia a un DataSource que ya está pooleado, en vez de darle los datos para que haga su propio pool.

Básicamente lo mismo que dice Enrique; suena totalmente a deadlock o que una transacción se abrio y esta bloqueado la tabla.

Por ejemplo si dos procesos están intentando modificar la misma tabla uno de los puede blquearse hasta que el otro le de commit a su transacción.

En alguna ocasión me pasó que alguién abrio su cliente ( creo que era TOAD ) para actualizar un registro pero olvidó darle commit y eso bloqueo toda la tabla hasta que el DBA mató su proceso. Suena que está pasando algo similar.

Pues estuve moviendole a todo lo que pude por e dia de hoy, no puedo invocar al   porque la excepcion se la traga y no la lanza (pero si tiene su debido try.

La tablano tiene boqueos (a menos que el mismo Hibernate lo haga) y puedo consultar la tabla y el registro digamos desde PGAdmin. He revisado que en todos los fallos haga el rollback correspondiente.

He modificado algunos parametros del hibernate.cfg.xml y creo que se puso mas ruda la cosa... que bueno que hay localHistory!!!

xin .. :) Pues si lo bueno es que hay localhistory

Puedes usar git o hg localmente eh, te ayudaría mucho para estos casos de rollback. :)

Resulta que me pase casi 1.5 dias haciendo pruebas con el pool de conexiones, configurando otro ambiente para probarlo y parametrizando e hibernate para evitar este problema.

Lacausa del conflicto la genero un   al POJO de la tabla (lo puse en ambos metodos de acceso tanto get como set) y bueno se me ocurrio haceruna prueba haciendo rollback de esa clase qe nadamas cambia eso que les digo del trim y sin hacer absoluamente nada.. naditita de nada funciono sin problemas (todo regreso a la normalidad)

Cielos, me seria interesante comprender WTHF! sucedio. Yo lo que queria evtar es hacerle el trim cada vez que obtengo una propiedad

suponiendo que la longitud es de 10 yo no queria obtener esto

 
masbien buscaba esto
 

en fin, ya ni modo seguire poniendo los trim() a lo largo del codigo

Guau!... que bien que le encontraste..

Si está super raro, pero acabas de encontrar una joya de la práctica de la programación que parece obvio pero a toma años en aprender ( bueno si alguien más te lo dice quizá solo te tome semanas ).

Si el sistema funcionaba, y ya no funciona, la causa está en el último cambio hecho!

Doh!.. verdad que parece obvio? Pues yo me di de topes muchas veces por no comprender esta sencilla regla de programación.

Lo hermoso de IDEA ( y ahora git o hg ) es que tiene un controlador de versiones local.

Cuando tengas tiempo trata de aislar el problema y replicarlo ( quizá no era el trim pero se le parecía mucho ) porque no lo dudes, te va a volver a pasar!

Kudos!!!

Cuando haces el trim, revisas nulos?

Si no revisas nulos, y tienes solamente algo como   entonces   va a arrojar una NPE y eso a la mitad de una transacción, dependiendo cómo la estés manejando, la puede dejar inestable o puede generar un rollback...

Me sucedio que trabajando con JPA la implementacion de Hibernate resulta ser una mala idea meter codigo en los accesores, no tengo idea de como este implementado pero hacia referencias a valores que no podia accesar si por ejemplo trataba de validar algo en el setter. Quiza sea eso. Por otro lado podrias tratar de cambiar el tipo en la BD por un varchar y olvidarte de los trims o tratarle con un mapper custom de hibernate, lo que sea pero no te llenes de trims.