I am a software architect passionate about software integration, high scalability and concurrency challenges. Vlad is a DZone MVB and is not an employee of DZone and has posted 64 posts at DZone. You can read more from them at their website. View Full User Profile

The Minimal Configuration for Testing Hibernate

06.11.2014
| 1879 views |
  • submit to reddit

In my previous post I announced my intention of creating a personal Hibernate course. The first thing to start with is a minimal testing configuration. The examples are relevant for Hibernate 4.

You only need Hibernate

In a real production environment you won’t use Hibernate alone, as you may integrate it in a JEE or Spring container. For testing Hibernate features you don’t need a full-blown framework stack, you can simply rely on Hibernate flexible configuration options.

Case 1: Driver based JDBC configuration

We first define a test Entity

@Entity
class SecurityId {
@Id
@GeneratedValue
private Long id;
private String role;
public Long getId() {
return id;
}
public String getRole() {
return role;
}
public void setRole(String role) {
this.role = role;
}
}

Thanks to Hibernate Transaction abstraction layer we are not forced to employ any external transaction manager or have to write any home-made transaction management code.

For testing purposes we can use the JDBC resource local transactions, which are managed internally by the default JdbcTransactionFactory.

We don’t even need to supply an external data source, as Hibernate is supplied with a non-production built-in connection pool represented byDriverManagerConnectionProviderImpl.

Our test code looks like this:

@Test
public void test() {
Session session = null;
Transaction txn = null;
try {
session = sf.openSession();
txn = session.beginTransaction();
SecurityId securityId = new SecurityId();
securityId.setRole("Role");
session.persist(securityId);
txn.commit();
} catch (RuntimeException e) {
if ( txn != null && txn.isActive() ) txn.rollback();
throw e;
} finally {
if (session != null) {
session.close();
}
}
}

We don’t need any external configuration file, so this is how we can build and configure a session factory:

@Override
protected SessionFactory newSessionFactory() {
Properties properties = new Properties();
properties.put("hibernate.dialect", "org.hibernate.dialect.HSQLDialect");
//log settings
properties.put("hibernate.hbm2ddl.auto", "update");
properties.put("hibernate.show_sql", "true");
//driver settings
properties.put("hibernate.connection.driver_class", "org.hsqldb.jdbcDriver");
properties.put("hibernate.connection.url", "jdbc:hsqldb:mem:test");
properties.put("hibernate.connection.username", "sa");
properties.put("hibernate.connection.password", "");
return new Configuration()
.addProperties(properties)
.addAnnotatedClass(SecurityId.class)
.buildSessionFactory(
new StandardServiceRegistryBuilder()
.applySettings(properties)
.build()
);
}

Case 2: Using a professional connection pool

If we want to replace the built-in connection pool with a professional one, Hibernate offers the choice of setting up c3p0 which is handled internally byC3P0ConnectionProvider.

We only need to change the session factory configuration properties:

protected SessionFactory newSessionFactory() {
Properties properties = new Properties();
properties.put("hibernate.dialect", "org.hibernate.dialect.HSQLDialect");
//log settings
properties.put("hibernate.hbm2ddl.auto", "update");
properties.put("hibernate.show_sql", "true");
//driver settings
properties.put("hibernate.connection.driver_class", "org.hsqldb.jdbcDriver");
properties.put("hibernate.connection.url", "jdbc:hsqldb:mem:test");
properties.put("hibernate.connection.username", "sa");
properties.put("hibernate.connection.password", "");
//c3p0 settings
properties.put("hibernate.c3p0.min_size", 1);
properties.put("hibernate.c3p0.max_size", 5);
return new Configuration()
.addProperties(properties)
.addAnnotatedClass(SecurityId.class)
.buildSessionFactory(
new StandardServiceRegistryBuilder()
.applySettings(properties)
.build()
);
}

Case 3: Using an external data-source

Since Hibernate doesn’t log SQL prepared statements parameters:

o.h.SQL - insert into SecurityId (id, role) values (default, ?)

We will add a datasource-proxy to intercept the actual SQL queries:

n.t.d.l.SLF4JQueryLoggingListener - Name: Time:0 Num:1 Query:{[insert into SecurityId (id, role) values (default, ?)][Role]}

The configuration looks like this:

@Override
protected SessionFactory newSessionFactory() {
Properties properties = new Properties();
properties.put("hibernate.dialect", "org.hibernate.dialect.HSQLDialect");
//log settings
properties.put("hibernate.hbm2ddl.auto", "update");
//data source settings
properties.put("hibernate.connection.datasource", newDataSource());
return new Configuration()
.addProperties(properties)
.addAnnotatedClass(SecurityId.class)
.buildSessionFactory(
new StandardServiceRegistryBuilder()
.applySettings(properties)
.build()
);
}
private ProxyDataSource newDataSource() {
JDBCDataSource actualDataSource = new JDBCDataSource();
actualDataSource.setUrl("jdbc:hsqldb:mem:test");
actualDataSource.setUser("sa");
actualDataSource.setPassword("");
ProxyDataSource proxyDataSource = new ProxyDataSource();
proxyDataSource.setDataSource(actualDataSource);
proxyDataSource.setListener(new SLF4JQueryLoggingListener());
return proxyDataSource;
}
Conclusion

This is the minimal configuration set-up we need for testing Hibernate features. I also use these configurations whenever I submit a Hibernate bug report accompanied by a replicating test case.

Code available on GitHub.

Published at DZone with permission of Vlad Mihalcea, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)