My team is also struggling to find ways to speedup Hibernate's session factory creation. In case you have not read my previous post, here is the background info:

Our application originally used a Versant object database, and we have converted our application to use Hibernate 3.1.3 to persist our data into MySQL 5.1.30-community. We are currently using Java 1.4.2_17 and MySQL connector 3.1.13, but we are moving to the latest of both Java and the MySQL connector in this release cycle. We have gone through great lengths to have no references to Hibernate except in core code, so ALL of our business logic operates on detached objects. Also our application has a client-server architecture, so we frequently send our data objects via RMI to the clients to operate in a separate JVM from the Hibernate persistence context. For these reasons, we map all entities and most collections with lazy="false".

I should point out that we have well over 1,000 mapped entity classes, which is likely to be unusual for most Hibernate users. As a result, it can take several minutes to start our application server. We're looking for ways to speed up the "building session factory" step of startup.

During deployment, the mapping files and such will not change so there is no reason to dynamically generate all of this information every time the server starts. So one idea I have tried is to persist all of the information generated for the session factory. The session factory itself has primarily transient fields, so you cannot simply serialize the object. I took a fairly quick look at the session factory, and it is quite a complex class. It was not immediately clear how I could save the information and recreate the factory manually.

Another thing I have learned about this process is that Hibernate creates all of its proxies while creating the session factory. I discovered this because the large number of entity classes causes Hibernate to create a large number of proxy classes, and we had to increase our Java PermGen size to accommodate. As I mentioned earlier, we NEVER use lazy loading for entity relationships. So my second idea was to disable the production of the proxies, since I figure that Hibernate may not need them if we never allow the lazy initialization of the entities. The only way I have found to "disable" the proxies is to declare the classes with lazy="false" in the hibernate mapping files rather than just the entity references. However, I saw no changes in the time it takes to build the session factory, nor did I see a decrease in the amount of PermGen space used. It appears that Hibernate still creates the proxies in this case. I should also mention that this change broke a lot of our queries because it complained about MySQL only being able to join 61 tables. I suspect that either (a) disabling these proxies simply had an unintended side effect or (b) Hibernate uses them internally to perform separate selects.

In the Hibernate 3.1 distribution, there is jaxen-1.1-beta-7.jar. According to documentation, this is "required if you want to deserialize a Configuration to improve startup performance". It's not immediately apparent to me if this would actually speed up the session factory creation, but it sounds promising. However, I have not found the first bit of information on how to accomplish this serialization.

I'm fresh out of ideas. If anyone has found ways to speed up the creation of the session factory, please advise.

Thanks,
Joe

This is a good question, we have similar issues.

Did anything come of this?

Cheers,

Nicholas