[TPA] mil problemas al deployar con Heroku

[foviedo]

Bueno, este issue es medio manotazo de ahogado, pero probé mil cosas y no sirvieron de mucho
La cosa es así, cuando deployeo en Heroku, en un inicio anda bien, pero en cuanto hago algo cercano a una query pesada (por ejemplo, registrar a un usuario) aparentemente se cae la conexión con la db
Datos relevantes: probé tanto con Cleardb MySql así como con JawsDB MySql, las versiones gratuitas claro
Una vez que se cayó una vez, no reconecta a la base de datos hasta que deployeo de nuevo. Uno de los errores que tira es:
WARN: SQL Error: 0, SQLState: 08003
Googleando, pareciera ser un error que ocurre por un timeout, tal vez porque la DB hace las consultas más rápido que lo que carga la página?
Cosas que fortalecen esta teoría:
-Al principio, cuando inicializo la base tarda 1 min y medio en hacer algo que localmente se hace en 10 segundos
-La página anda lenta en sí
-Cuando la corro desde localhost a la web (pero la db sigue estando online y no local), anda todo bien
Sosteniéndome de esto, en el persistence.xml traté de usar esto
            
Pero no sirvió

Además, volvieron errores similares a los dichos en #86, pero esta vez con las cosas que se persisten dentro de la UI incluso aunque tenga ya puesto esto

	after((request, response) -> {
        PerThreadEntityManagers.getEntityManager();
        PerThreadEntityManagers.closeEntityManager();
    });

y que cada operación con la db que hago

	EntityTransaction transaccion = em.getTransaction(); //em es un PerThreadEntityManager
	transaccion.begin();
	em.persist(loQueQuieraPersistir);
	transaccion.commit();

Aclaro de nuevo, entiendo que lo que sea cae es la conexión con la db y no la propia db

Se les ocurre qué puede llegar a ser y cuál puede ser la solución? Una que no implique tarjetas de crédito de ser posible (?
Tienen idea de si hay forma de volver a levantar la conexión con la db sin tener que deployar de nuevo? En google vi que había que poner un flag de autoreconect en el persistence.xml pero no sirvió de mucho la verdad o yo no entendí cómo usarla
Debería recursar la materia? Espero que no (?

Gracias de antemano

[gastonprieto]

Buenas @foviedo !

Para lo que es que la conexión se mantenga viva y no usar una única conexión, se usa lo que se conoce como pools de conexiones, para no estar conectando, desconectandote (esto es costoso en el caso de las base de datos), tenes un objeto que se encarga de conectarse varias veces y mantener vivas esas conexiones. Hibernate te deja configurar esto por el persistence.xml.

Te dejo un ejemplo de biblioteca que sirve para eso c3po (donde dice hibernate.cfg.xml, es el persistence.xml) y podes configurarle la query para saber si la conexión esta viva con esto normalmente se usa un select 1

Googleando, pareciera ser un error que ocurre por un timeout, tal vez porque la DB hace las consultas más rápido que lo que carga la página?

Esto no me cierra, porque si hace la consultas rapido, significa que tu sitio se va a renderizar rapido.

-Al principio, cuando inicializo la base tarda 1 min y medio en hacer algo que localmente se hace en 10 segundos

Cuando arranque es normal que tarde porque se levanta la aplicación, mas allá de eso seguramente tarde mas porque es una maquina peor la que te dan en una cuenta gratis.

Podes ir viendo en los logs que va pasando para saber cual es el problema.

Sosteniéndome de esto, en el persistence.xml traté de usar esto

Te falto el esto :P

y que cada operación con la db que hago

EntityTransaction transaccion = em.getTransaction(); //em es un PerThreadEntityManager
transaccion.begin();
em.persist(loQueQuieraPersistir);
transaccion.commit();

No se como lo tenes examente en tu código, pero esto no parece ser así, vos tenes que abrir y cerrar las transacciones donde arrancan y terminan tus casos de uso, en este caso en los controllers, cada operación POST/PUT/DELETE deberían tener ese cacho de código y no realizarse mas abajo (por ejemplo, no en los repositorios) porque sino estan cambiando la atomicidad de las operaciones. Solo hay que hacerle persist a los objetos nuevos, los update hibernate se da cuenta que cambiaron y los actualiza.

[foviedo]

Buen día!

Para lo que es que la conexión se mantenga viva y no usar una única conexión, se usa lo que se conoce como pools de conexiones, para no estar conectando, desconectandote (esto es costoso en el caso de las base de datos), tenes un objeto que se encarga de conectarse varias veces y mantener vivas esas conexiones. Hibernate te deja configurar esto por el persistence.xml.

En su momento traté de usar c3p0 porque tutoriales de google y no me funcionó, pero tampoco lo intenté demasiado, voy a volver a fijarme
Curiosamente volvió a reconectarse hoy sin tener que deployar de nuevo. Así que por lo visto hace una reconexión cada mucho tiempo

Esto no me cierra, porque si hace la consultas rapido, significa que tu sitio se va a renderizar rapido.

Tiene sentido, pero a mí me genera la duda, qué es lo que está cortando la conexión? La página porque se cansó de esperar a la transacción lenta de la base de datos? Reitero que si tengo la web de forma local esto no ocurre (por más que siga teniendo la db de forma remota)

Podes ir viendo en los logs que va pasando para saber cual es el problema.

Vos sabés que ahora no lo estoy pudiendo hacer estallar por otro medio que no sea la pantalla de registrarme
Y en la pantalla de registrarme tengo un catch de Exception (lo cual está mal, lo sé) que simplemente devuelve 500
Voy a sacarlo para ver qué no me estaría dejando registrarme y avisaré luego

Te falto el esto :P

Mala mía, esto
<property name="javax.persistence.query.timeout" value="999999999"/>            

No se como lo tenes examente en tu código, pero esto no parece ser así, vos tenes que abrir y cerrar las transacciones donde arrancan y terminan tus casos de uso, en este caso en los controllers, cada operación POST/PUT/DELETE deberían tener ese cacho de código y no realizarse mas abajo (por ejemplo, no en los repositorios) porque sino estan cambiando la atomicidad de las operaciones. Solo hay que hacerle persist a los objetos nuevos, los update hibernate se da cuenta que cambiaron y los actualiza.

AH, esto es relevante
Sólo para asegurarme, aunque no vaya a hacer .persist tengo hacer todo adentro de una transaction no?

Gracias, voy a estar revisando esas cosas mencionadas

[foviedo]

Perdón, otra pregunta si yo en una de esas a un Egreso que ya está persistido, le agrego un item que no está persistido. Debería hacer .persist(unItem)? O sólo con agregarlo a la lista de items del egreso basta para que se haga todo bien?

[julchat]

Una cosa mas Gas, en el issue #86 mencionaste:
"En el job tienen que borrar/limpiar las cosas que buscaron porque sino quedan cachedas."
Como se realiza esa limpieza?

[gastonprieto]

Tiene sentido, pero a mí me genera la duda, qué es lo que está cortando la conexión? La página porque se cansó de esperar a la transacción lenta de la base de datos?

Esto puede ser, cuando vos haces una request a un servidor los clientes suelen tener un timeout, así que tal vez esta timeouteando el cliente, o tal vez esta timeouteando el balancer de Heroku que le esta pegando a tu App.

Depende que estes viendo si 500 o timeout, puede estar en distintos lugares el problema.

Lo de c3po debería mejorar el tema conexiones.

Claro, esto fuerza a JPA a esperar, pero no significa que el que te pidio la request te este esperando. Siempre es bueno usar valores mas pequeños, porque si en X tiempo no respondio la query entonces no vale la pena esperarla.

Sólo para asegurarme, aunque no vaya a hacer .persist tengo hacer todo adentro de una transaction no?

Si.

Perdón, otra pregunta si yo en una de esas a un Egreso que ya está persistido, le agrego un item que no está persistido. Debería hacer .persist(unItem)? O sólo con agregarlo a la lista de items del egreso basta para que se haga todo bien?

En este caso tenes dos opciones

1. em.persist(item)
2. en la annotation le pones cascade persist y te lo evitas @OneToMany(cascade = CascadeType.PERSIST)

[gastonprieto]

"En el job tienen que borrar/limpiar las cosas que buscaron porque sino quedan cachedas."

Esto es lo mismo que se hace en el after, el
PerThreadEntityManagers.closeEntityManager
Quita los valores de la cache de identidad de Hibernate

[foviedo]

Al final nos re sirvió, fue una combinación de varios factores o de uno de ellos y no me enteré cuál(?
Gracias!