“weekly status” – was a wrong header for the letter. "hibernate.temp.use_jdbc_metadata_defaults", "false" ); - is false not a true? looong timeouts for non-running databases + i havent been needed until now... wc.setAttribute("hibernate.temp.use_jdbc_metadata_defaults", true); without getConnection? if that is not enough ask the user for the db, è if ( useJdbcMetadata ) { it is possible to cache databaseName & databaseMajorVersion to read it only once… Firstly I think just simple properties: databaseName & databaseMajorVersion be suitable… If useJdbcMetadata and databaseName == null & databaseMajorVersion == null Then get connection and initialize as it is. So it call getConnection only once – but this is SettingsFactory – not suitable solution… It seems like a “if ( useJdbcMetadata ) {” block – not a right place in SettingsFactory -> buildSettings, seems should be parameters for buildSettings function - databaseName, databaseMajorVersion. databaseName, databaseMajorVersion – should be initialized from other place. In any case not a subject to discuss - if Just setAttribute("hibernate.temp.use_jdbc_metadata_defaults", true) or autoConfigureDialect (better if not a job of hibernate core) could be a nice feature, It prevent user to make one more configuration step to setup dialect by hands… It’ a pity if not possible to use “hibernate.temp.use_jdbc_metadata_defaults” or autoConfigureDialect … May be the solution is to get databaseName & databaseMajorVersion or in general dialect in independent thread – only synchronization issue, So Hibernate Console Config could display it’s nodes and in case when the user try to expand “Database” (here is a try to connect to db in any case) - db dialect could get its value. But in case if db dialect doesn’t get value – the user should specify this by hands… Look like too much “could” and “but”, but this is only specific cases – in general it seems useful and possible to use (autoConfigureDialect in independent thread). In the bad case we just get a long running thread. Vitali