Beware of the Hibernate traps

Today most Java programmers use some type of JPA like Hibernate or TopLink to traverse the world of Objects and Relations Databases like Oracle. These apis or frameworks are called as ORMs (Object Relational Models) were invented to let Java developers who some assumed, could only see the world as full of objects or classes  and wanted to insulate these poor souls from the traumatic experience of writing simple SQLs and deal with the relational world of databases. So in came tools like Hibernate that let Java programmers deal with rows and tables as objects or entities while the tool itself would generate the actually SQLs that interfaced with the databases. Any time we have tools generating code or SQLs one must be wary because the authors of those tools while covering 80% of common usage cannot cover situations that are exceptional or uncommon. This is especially true when Java programmers use Hibernate to deal with very large data sets that have a lot of foreign key constraints embedded in the database. Some of the things to keep in mind while using ORMs like Hibernate are: 1. Make sure you annotate your Hibernate code to use Joins instead of simple query, and avoid the N+1 issue when fetching records from tables that have foreign keys. This is because Hibernate will fetch the entire parent table first and for each row of parent fetch the child tables. This is extremely expensive when dealing with large data sets. 2. Avoid annotations like "eager fetches" since this will force Hibernate to cache all tables and their child tables causing your JVM heap to fill and slow performance. Also check the max_fetch_depth setting so that you don't fetch a child table's child as well and so on. 3. Understand the L2 cache of Hibernate and the use of Read/Write strategy. In general a read/write cache as the name says is used to cache object changes and then persist them later to the database. But this read/write cache can be a source of contention during heavy DML changes since Hibernate now is acting like a DB synchronizing access to objects so that integrity is maintained. This can lead to locks within Hibernate cache where threads that have a need to synchronize method execution of Hibernate's internal code will block, slowing transactions. 4. Hibernate on average will generate more SQLs to the database to get the same job done compared to what one can write manually. Liberal use of Outer Joins, fetching all columns whether one needs it or not are all extra work to the database. It is best for Java developers to learn basic SQLs and construct SQLs themselves when dealing with large and complex data sets. In the end let the DB handle what it was built to do which is execute SQL, maintain caching, integrity etc There is no substitute for business and technical knowledge that developers have, any code generator however good will always fall short, so don't take the short cut, just learn some SQL!