{"id":842,"date":"2012-05-21T09:40:45","date_gmt":"2012-05-21T14:40:45","guid":{"rendered":"http:\/\/alejandroayala.solmedia.ec\/?p=842"},"modified":"2012-11-14T08:59:41","modified_gmt":"2012-11-14T13:59:41","slug":"hiberte-y-postgres-transacciones","status":"publish","type":"post","link":"https:\/\/alejandroayala.solmedia.ec\/?p=842","title":{"rendered":"Hibernate y Postgres. El dolor de cabeza idle in transaction"},"content":{"rendered":"

Generalmente al trabajar con base de datos en este caso usando java, la gran mayor\u00eda de los desarrollos utilizan un framework de persistencia. El m\u00e1s usado\u00a0parece\u00a0ser Hibernate<\/a>, que nos facilita en gran cantidad el trabajo de estar\u00a0preocup\u00e1ndonos\u00a0por abrir y cerrar conexiones.<\/p>\n

Es recomendable que todas las consultas que generemos inclusive los SELECT<\/em> est\u00e9n encapsuladas en transacciones, de tal manera que si por alguna raz\u00f3n nuestro c\u00f3digo genera una excepci\u00f3n la conexi\u00f3n manejada correctamente en un bloque finally<\/a><\/em> por ejemplo deber\u00edamos cerrar la conexi\u00f3n para evitar que quede \u00abcolgada\u00bb de la base de datos.<\/p>\n

Mediante PgAdmin podemos verificar aquellas conexiones que se quedaron colgadas, esto es muy peligroso y puede ocacionar que nuestro sistema ya no pueda establecer conexion con nuestra base de datos y por consiguiente el sistema dejar\u00e1 de funcionar.<\/p>\n

<\/p>\n

Veremos unas notificaciones de este estilo:<\/p>\n

postgres: <dbname> <dbname> <host> idle in transaction<\/strong><\/p>\n

EL pool de conexiones se llenar\u00e1 r\u00e1pidamente, la memoria RAM se agotar\u00e1, la aplicaci\u00f3n bloquer\u00e1 el intento de conexiones y la cat\u00e1strofe se har\u00e1 presente.<\/p>\n

Personalmente puedo decir que esto puede ocurrir por fallas en la programaci\u00f3n de la aplicaci\u00f3n, generalmente los programadores lo negar\u00e1n todo y echar\u00e1n la culpa a la base de datos y se negar\u00e1n a revisar sus procedimientos, de mi experiencia puedo asegurar que en todos los casos que he estado involucrado con el desarrollo de sistema, este problema se ha solucionado verificando la programaci\u00f3n, rectificando procedimientos\u00a0err\u00f3neos\u00a0o quitando varios accesos innecesarios a la base de datos.<\/p>\n

Por ello mi \u00fanica recomendaci\u00f3n en este caso es: \u00abRevisar la programaci\u00f3n\u00bb, indicar a los programadores que deben cerrar siempre las conexiones, y en el caso de usar hibernate, encerrar todas las query, inclusive los SELECT<\/em> en transacciones, con sus respectivos bloques try, catch y finally.<\/p>\n

Basicamente lo que deber\u00eda incluirse en nuestra programaci\u00f3n es lo siguiente:<\/p>\n

[java]
\norg.hibernate.Session dbSession = HibernateUtil.getSession();
\ndbSession.getTransaction().begin();<\/p>\n

… tu c\u00f3digo aqui …<\/p>\n

dbSession.getTransaction().commit();
\ndbSession.close();
\n[\/java]<\/p>\n

Como dije antes tambi\u00e9n es recomendable manejar las excepciones, y el cierre de la transacci\u00f3n deSession.close <\/em><\/strong>\u00a0deber\u00eda ir en el bloque finally<\/a><\/em> as\u00ed siempre se cerrar\u00e1 la conexi\u00f3n inclusive si nuestro c\u00f3digo generara una excepci\u00f3n.<\/p>\n

Mas informaci\u00f3n:<\/p>\n

https:\/\/wiki.duraspace.org\/display\/DSPACE\/Idle+In+Transaction+Problem<\/a><\/p>\n\n

Twittear<\/a><\/div>\n","protected":false},"excerpt":{"rendered":"

Generalmente al trabajar con base de datos en este caso usando java, la gran mayor\u00eda de los desarrollos utilizan un framework de persistencia. El m\u00e1s usado\u00a0parece\u00a0ser Hibernate, que nos facilita en gran cantidad el trabajo de estar\u00a0preocup\u00e1ndonos\u00a0por abrir y cerrar conexiones. Es recomendable que todas las consultas que generemos inclusive los SELECT est\u00e9n encapsuladas en\u2026 Leer m\u00e1s »<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":690,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0},"categories":[4],"tags":[173,175,506,138,139,174],"_links":{"self":[{"href":"https:\/\/alejandroayala.solmedia.ec\/index.php?rest_route=\/wp\/v2\/posts\/842"}],"collection":[{"href":"https:\/\/alejandroayala.solmedia.ec\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/alejandroayala.solmedia.ec\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/alejandroayala.solmedia.ec\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/alejandroayala.solmedia.ec\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=842"}],"version-history":[{"count":10,"href":"https:\/\/alejandroayala.solmedia.ec\/index.php?rest_route=\/wp\/v2\/posts\/842\/revisions"}],"predecessor-version":[{"id":994,"href":"https:\/\/alejandroayala.solmedia.ec\/index.php?rest_route=\/wp\/v2\/posts\/842\/revisions\/994"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alejandroayala.solmedia.ec\/index.php?rest_route=\/wp\/v2\/media\/690"}],"wp:attachment":[{"href":"https:\/\/alejandroayala.solmedia.ec\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=842"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alejandroayala.solmedia.ec\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=842"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alejandroayala.solmedia.ec\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=842"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}