Hibernate Lento para adquirir la conexión de Postgres

Estoy teniendo un momento realmente difícil para solucionar este problema. Cada vez que trato de establecer una conexión con postgres, toma un minuto completo. Una vez establecida la conexión, todo está bien. Intenté deshabilitar todas las asignaciones y no cargar ninguna, pero la conexión tarda mucho tiempo en adquirirse. También intenté deshabilitar la validación, sin diferencia. Cuando uso una conexión JDBC sencilla y simple, es instantáneo. Hibernate está haciendo algo que lleva bastante tiempo y parece que no puedo reducirlo. ¡Cualquier aporte es muy apreciado!Hibernate Lento para adquirir la conexión de Postgres

Postgres conductor:

postgresql-9.1-901.jdbc4.jar

ajustes de configuración:

<hibernate-configuration> 
    <session-factory> 
    <!-- properties --> 
     <property name="dialect">org.hibernate.dialect.PostgreSQLDialect</property> 
     <property name="connection.driver_class">org.postgresql.Driver</property> 

     <property name="connection.url">jdbc:postgresql://xxxx.com:5432/xxxxx</property> 
     <property name="connection.username">xxxxxxx</property> 
     <property name="connection.password">xxxxxxx</property> 

    </session-factory> 
</hibernate-configuration>

Ajustes adicionales en código:

config.setProperty("hibernate.hbm2ddl.auto", hbm2ddlMode); 
    //config.setProperty("hibernate.cache.use_query_cache", "true"); 
    config.setProperty("hibernate.cache.use_second_level_cache", "true"); 
    //config.setProperty("hibernate.cache.region.factory_class", "net.sf.ehcache.hibernate.EhCacheRegionFactory"); 
    config.setProperty("hibernate.cache.provider_class", "org.hibernate.cache.EhCacheProvider"); 
    //config.setProperty("hibernate.cache.provider_class", "org.hibernate.cache.NoCacheProvider"); 
    config.setProperty("hibernate.jdbc.fetch_size", "100"); 
    config.setProperty("hibernate.jdbc.batch_size", "30"); 
    config.setProperty("hibernate.jdbc.use_scrollable_resultset", "true"); 
    config.setProperty("hibernate.connection.provider_class", "org.hibernate.connection.C3P0ConnectionProvider"); 

    config.setProperty("hibernate.c3p0.acquire_increment", "1"); 
    config.setProperty("hibernate.c3p0.idle_test_period", "0"); 
    config.setProperty("hibernate.c3p0.min_size", "1"); 
    config.setProperty("hibernate.c3p0.max_size", "2"); 
    config.setProperty("hibernate.c3p0.timeout", "0"); 
    config.setProperty("javax.persistence.validation.mode", "none");

aquí está el segmento de código en el que el retraso se produce:

private SessionFactory buildSessionFactory() throws Exception { 
     ServiceRegistry serviceRegistry = new ServiceRegistryBuilder().applySettings(config.getProperties()).buildServiceRegistry(); 

      //Building session takes a whole minute without mappings!!! 
     sessionFactory = config.buildSessionFactory(serviceRegistry); 

     validateConnection(); 

     return sessionFactory; 
    }

He aquí los resultados de registro:

[main] 2012-04-09 10:40:32,823 110391 INFO C3P0ConnectionProvider - HHH000046: 
Connection properties: {user=hgaidb_test, password=****} 
[main] 2012-04-09 10:40:32,823 110391 INFO C3P0ConnectionProvider - HHH000006: 
Autocommit mode: false 
[main] 2012-04-09 10:40:34,100 111668 DEBUG JdbcServicesImpl - Database -> 
     name : PostgreSQL 
    version : 8.3.3 
     major : 8 
     minor : 3 
[main] 2012-04-09 10:40:34,101 111669 DEBUG JdbcServicesImpl - Driver -> 
     name : PostgreSQL Native Driver 
    version : PostgreSQL 9.1 JDBC4 (build 901) 
     major : 9 
     minor : 1 
******************************************************************************* 
// 1 MINUTE DELAY 
******************************************************************************* 
[main] 2012-04-09 10:40:34,102 111670 DEBUG JdbcServicesImpl - JDBC version : 4. 
0 
[main] 2012-04-09 10:41:21,632 159200 INFO Dialect - HHH000400: Using dialect: 
org.hibernate.dialect.PostgreSQLDialect 
******************************************************************************* 
[main] 2012-04-09 10:41:21,669 159237 INFO LobCreatorBuilder - HHH000424: Disab 
ling contextual LOB creation as createClob() method threw error : java.lang.refl 
ect.InvocationTargetException 
[main] 2012-04-09 10:41:21,814 159382 DEBUG SettingsFactory - Automatic flush du 
ring beforeCompletion(): disabled 
[main] 2012-04-09 10:41:21,814 159382 DEBUG SettingsFactory - Automatic session 
close at end of transaction: disabled 
[main] 2012-04-09 10:41:21,815 159383 DEBUG SettingsFactory - JDBC batch size: 3 
0 
[main] 2012-04-09 10:41:21,816 159384 DEBUG SettingsFactory - JDBC batch updates 
for versioned data: disabled 
[main] 2012-04-09 10:41:21,816 159384 DEBUG SettingsFactory - Scrollable result 
sets: enabled 
[main] 2012-04-09 10:41:21,817 159385 DEBUG SettingsFactory - Wrap result sets: 
disabled 
[main] 2012-04-09 10:41:21,818 159386 DEBUG SettingsFactory - JDBC3 getGenerated 
Keys(): enabled 
[main] 2012-04-09 10:41:21,818 159386 DEBUG SettingsFactory - JDBC result set fe 
tch size: 100 
[main] 2012-04-09 10:41:21,819 159387 DEBUG SettingsFactory - Connection release 
mode: auto 
[main] 2012-04-09 10:41:21,819 159387 INFO TransactionFactoryInitiator - HHH000 
399: Using default transaction strategy (direct JDBC transactions) 
[main] 2012-04-09 10:41:21,844 159412 DEBUG SettingsFactory - Default batch fetc 
h size: 1 
[main] 2012-04-09 10:41:21,844 159412 DEBUG SettingsFactory - Generate SQL with 
comments: disabled 
[main] 2012-04-09 10:41:21,845 159413 DEBUG SettingsFactory - Order SQL updates 
by primary key: disabled 
[main] 2012-04-09 10:41:21,846 159414 DEBUG SettingsFactory - Order SQL inserts 
for batching: disabled 
[main] 2012-04-09 10:41:21,846 159414 DEBUG SettingsFactory - Query translator: 
org.hibernate.hql.internal.ast.ASTQueryTranslatorFactory 
[main] 2012-04-09 10:41:21,867 159435 INFO ASTQueryTranslatorFactory - HHH00039 
7: Using ASTQueryTranslatorFactory 
[main] 2012-04-09 10:41:21,867 159435 DEBUG SettingsFactory - Query language sub 
stitutions: {} 
[main] 2012-04-09 10:41:21,867 159435 DEBUG SettingsFactory - JPA-QL strict comp 
liance: disabled 
[main] 2012-04-09 10:41:21,868 159436 DEBUG SettingsFactory - Second-level cache 
: enabled 
[main] 2012-04-09 10:41:21,868 159436 DEBUG SettingsFactory - Query cache: disab 
led 
[main] 2012-04-09 10:41:21,869 159437 DEBUG SettingsFactory - Cache region facto 
ry : org.hibernate.cache.internal.NoCachingRegionFactory 
[main] 2012-04-09 10:41:21,872 159440 DEBUG SettingsFactory - org.hibernate.cach 
e.internal.NoCachingRegionFactory did not provide constructor accepting java.uti 
l.Properties; attempting no-arg constructor. 
[main] 2012-04-09 10:41:21,873 159441 DEBUG SettingsFactory - Optimize cache for 
minimal puts: disabled 
[main] 2012-04-09 10:41:21,873 159441 DEBUG SettingsFactory - Structured second- 
level cache entries: disabled 
[main] 2012-04-09 10:41:21,873 159441 DEBUG SettingsFactory - Statistics: disabl 
ed 
[main] 2012-04-09 10:41:21,874 159442 DEBUG SettingsFactory - Deleted entity syn 
thetic identifier rollback: disabled 
[main] 2012-04-09 10:41:21,874 159442 DEBUG SettingsFactory - Default entity-mod 
e: pojo 
[main] 2012-04-09 10:41:21,875 159443 DEBUG SettingsFactory - Named query checki 
ng : enabled 
[main] 2012-04-09 10:41:21,875 159443 DEBUG SettingsFactory - Check Nullability 
in Core (should be disabled when Bean Validation is on): enabled 
[main] 2012-04-09 10:41:21,876 159444 DEBUG SettingsFactory - multi-tenancy stra 
tegy : NONE

que he hecho un poco más investigación sobre esto, paso a paso por el depurador. No tengo toda la fuente en mi classpath, pero todavía puedo ver las variables. Durring que uno minutos de espera, hibernación está consultando la tabla pg_catalog.pg_type:

[SELECT typname FROM pg_catalog.pg_type WHERE oid = , ]

Aquí hay una captura de pantalla:

DebugWindow

Fuente

2012-04-09 Jason Huntley

Tal retraso puede deberse a problemas de DNS, intente utilizar la dirección IP en lugar del nombre de dominio en 'connection.url' para descartarlo. – axtavt

Lo intenté por IP, todavía no hay diferencia en los tiempos de adquisición. –

Vea también: http://stackoverflow.com/questions/23969399/persistence-createentitymanagerfactory-takes-very-long-time-to-return – Dojo

Lo arreglé =) Realmente tuve que buscar algo para encontrar la respuesta. Básicamente, se trata de cargar metadatos y el controlador JDBC. Está cargando TODOS LOS DATOS META, incluidos los comentarios junto a las columnas sql y otras construcciones diversas, que no son necesarios para la operación. No sé por qué esto está activado por defecto, pero que sin duda debe desactivar esta función a menos que explícitamente se necesita: conexión

config.setProperty("hibernate.temp.use_jdbc_metadata_defaults","false");

instantáneo ahora!

La única información que pude encontrar en esto es en código:

107  // 'hibernate.temp.use_jdbc_metadata_defaults' is a temporary magic value. 
108  // The need for it is intended to be alleviated with future development, thus it is 
109  // not defined as an Environment constant... 
110  // 
111  // it is used to control whether we should consult the JDBC metadata to determine 
112  // certain Settings default values; it is useful to *not* do this when the database 
113  // may not be available (mainly in tools usage). 
114  boolean useJdbcMetadata = ConfigurationHelper.getBoolean("hibernate.temp.use_jdbc_metadata_defaults", configValues, true);

http://grepcode.com/file/repo1.maven.org/maven2/org.hibernate/hibernate-core/4.1.1.Final/org/hibernate/engine/jdbc/internal/JdbcServicesImpl.java#JdbcServicesImpl

Fuente

2012-04-11 15:23:55

¡Guau! ¡Esto también lo solucionó! – trusktr

Según mi experiencia, este dialecto de hibernación realmente funcional tiene que definirse explícitamente. De lo contrario, produce fallas al inicio de la aplicación (al menos para PostgreSQL 9.3 e Hibernate 4). – chalda

SchemaUpdate puede verse afectado al deshabilitarlo. – Njax3SmmM2x2a0Zf7Hpd

esto suena vagamente a un problema que vimos en Ruby on Rails. Es posible buscar una causa similar a lo que he descrito aquí:

http://archives.postgresql.org/pgsql-performance/2009-11/msg00128.php

En resumen, el problema fue causado por registro explícito del controlador JDBC desde múltiples contextos ClassLoader.

Fuente

2012-04-09 15:16:59 kgrittn

que tenía que permitir también hibernate.jdbc.use_get_generated_keys lo contrario estrategia de generación de identidad estaba lanzando una excepción. Antes se habilitaba automáticamente en base a los metadatos recibidos de DB. Entonces toda mi solución fue agregar las siguientes dos líneas a la persistencia.xml:

<property name="hibernate.jdbc.use_get_generated_keys" value="true" /> 
<property name="hibernate.temp.use_jdbc_metadata_defaults" value="false" />

Fuente

2015-10-03 01:08:45 mmm

¡Gracias! Trabajó con Hibernate 5.2, Spring Framework 4.3 y PostgreSQL JDBC 4.2 – Chu

Un servidor PostgreSQL puede contener varias bases de datos. Desafortunadamente no se puede hide other-database metadatas to one connection, ¡por eso la lectura de metadatos lleva mucho tiempo con el jdbc-driver!

Separe estas bases de datos en diferentes servidores de postgres y se aumentará el rendimiento de la lectura de metadatos.

Lea how to seperate on centos.

Fuente

2016-04-27 10:10:51

Hibernate Lento para adquirir la conexión de Postgres

Respuesta

Cuestiones relacionadas