views:

236

answers:

3

I'm using Spring's AbstractTransactionalDataSourceSpringContextTests for my persistence unit tests and my problem is my tests are too slow: 1 method=5s, and each additional method is at least another second. I've over 300 db tables so a slow startup is perhaps understandable. However I've gone through the logs and one of the surprising things is that the Hibernate sessionFactory is rebuilt for each test method. And it's half the runtime cost of each additional method.

Shouldn't I be able to reuse the original sessionFactory?

I've delved a little into the source code and I haven't seen an obvious way to force the sessionFactory to be reused.

Any ideas?

And any other ideas for speeding up persistence unit tests?

(Spring 2.5 and Hibernate 3.2ish, hsqldb)

A: 

You should try to locate where sessionFactories are created (my bet would be that somehow a new one is created in every setUp() method). Then you can move the creation into a separate class, maybe into a static method, which makes sure internally that only one instance of it is created (kinda like a Singleton).

Péter Török
+1  A: 

You should write a helper class or so so that you could wrap your ISessionFactory API, and you had better make it static, so it is only created once as this API is very expensive to instantiate.

Will Marcouiller
A: 

Our entire SpringContext was getting refreshed each time which I thought was vaguely related to some dynamic spring context juggling we do. However the juggling is on a per class basis so doing a refresh for each method was entirely unnecessary.

The 'solution', such as it is, is to skip the context refresh which avoids the session factory recreation.

I'm still not sure why Spring feels the need to rebuild the session factory from scratch for each refresh. I suppose a rebuild for them is the simplest way to do a session refresh but it's hopefully not the quickest.

Thanks for the responses.

Brel