How to keep Hibernate mapping use under control as requirements grow

Question

I've worked on a number of Java web apps where persistence is via Hibernate, and we start off with some central class (e.g. an insurance application) without any time being spent considering how to break things up into manageable chunks. Over time as features are added we add more mappings (rates, clients, addresses, etc.) and then amount of time spent saving and loading an insurance object and everything it connects to grows. In particular you get close to a go-live date and performance testing with larger amounts of data in each table is starting to demonstrate that it's all too slow.

Obviously there are a number of ways that we could attempt to partition things up, e.g. map only the client classes for the client CRUD screens, etc., which would have been better to get in place earlier rather than trying to work it in at the end of the dev cycle.

I'm just wondering if there are recommendations about ways to handle/mitigate this.

Answer 1

Does Java have a port of this? http://fluentnhibernate.org/ It should ease your life, speed things up, plus it offers many other benefits.

Edit: To add, it's often much cheaper to simply throw hardware at the problem. If things are too slow it's worth spending a couple $100 or $1000 on hardware rather than embarking on a lengthy (read: costly) re-engineering effort.

Answer 2

If you aren't making use of Hibernate's lazy associations, this may be the place to start. Converting can be a challenge, as you'll discover how much code assumes the whole graph is loaded when you don't have a Session open. In which case, you'll need this pattern.

Answer 3

This type of problem can quickly devolve into an ugly religious debate. Many aspects of the drawbacks of ORMs have been discussed here. It is hard to have a discussion in this area however without digressing into a religious war. ORM's are great, but for some situations, maybe not the best fit. Perhaps you are experiencing a situation where the ORM is an impediment regarding what your system needs to accomplish. Perhaps not, and some Hibernate experts can navigate you through the shoals.

Answer 4

A couple of tricks:

• Dont use eager fetching. If you are using annotation, your should make sure that every *ToMany annotations are made lazy (fetch=...LAZY). Eager fetching is evil. If for some reason you really want eager fetching, you can always specify it in the query.

• Dont load too much objects in a single transaction. Say you have a transaction that will process a large amount of entities (> 1000). You should use some pagination and process each page in it's own transaction. Loading a lot of objects in a single transaction will load the session and performance will degrade. Alternatively, you could evict objects that are not used anymore but this can be tricky if an object graph is loaded.

A final note: I have used hibernate on systems with more than 300 tables and with tables having > 30 millions records. Tables have a lot of relations and we don't see any performance issues with the database.