When googling disadvantages of hibernate, you would find lots of discussions and arguments as to what works and what not in hibernate. This is year 2011 and Hibernate 3.2 has been released . An an ORM framework it has matured a lot . I will sum down my experience of working with hibernate so far
1. If it is a small project with few tables , I think there is no need for a full fledge ORM framework like hibernate. You can very well using Spring with JDBC and keep complexity to minimum.
But this is a classic mistake made by teams initially. You assume that the project will have only 3-4 tables and few updates and inserts, but as and when you gather requirements, dive deep into design , add more features, it starts to get bigger.
At later stage you wishes you had started with ORM framework else you might have to write all the inserts, updates and selects which is a huge waste of time ,considering all this can be configured easily by hibernate.
2. Performance : A lot is being talked about hibernate performance. We have used Spring and hibernate with one of the biggest deployment in clinical applications and I can tell you, I have not seen any issues or so because of hibernate.
Yes we had to fix the hqls at few places but that is a normal tuning process.
3. Hibernate is slow because it uses run time reflection: People who had faced performance issues with reflection in early ears were skeptical about hibernate’s use of reflection. But not anymore. You should not worry about performance loss due to reflection. From hibernate’s doc
Modern JVMs implement reflection extremely efficiently and the overhead is minimal compared to the cost of disk access or IPC. Developers from other traditions (eg. Smalltalk) have always relied upon reflection to do things that C/C++ needs code-generation for.
In the very latest versions of Hibernate, “reflection” is optimized via the CGLIB runtime bytecode generation library. This means that “reflected” property get / set calls no longer carry the overhead of the Java reflection API and are actually just normal method calls. This results in a (very) small performance gain.
A lot has been said and discussed about hibernate performance.I will not go into details and benchmarks but I will share some practical insights.
Our application was developed using Spring framework 2.5 , spring webflow and hibernate 3.0. We had Oracle application server (not the oracle weblogic ) and oracle database 10g
Caching : Second level caching was done using ehcache. The caching strategy was read-only which is the simplest and best-performing cache strategy
Stored Procedures : Procs were used at couple of places. These procs had business logic and were communicating with another database through DB Link.
Native queries : We did not use any native queries.
We have used Spring and hibernate with one of the biggest deployment in applications and I can tell you, I have not seen any issues or so because of hibernate.
Yes we had to fix the hqls at few places but that is a normal tuning process.
I cannot share much details here neither the performance statistics but will be happy to answer your questions.
When working with hibernate, one of the most used methods would be session.get or session.load.
Let us see what the difference between these tow
Take a look at this code :
Session hSession = this.getCurrentSession();
User u = (User)hSession.get(User.class, 8);
session.get() makes a hit to the database to get the data if the obejct does not
exist in the application.
Session.load gets the proxy for the instance, hence saving a database trip.But if there was no such object in the database then the method session.load() throws an exception whereas session.get() returns null.
Both the methods will return the instance or a proxy for the instance, if the instance or
proxy is already associated with the session.Only difference is that the session.load()
will throw an exception if the persistent entity does not exist in the database
In hibernate if you set this in you code
What does it signify ?
It means that the Hibernate session not to flush any state changes to database unless flush() is explicitly called by the application.
When setting the FlushMode.NEVER , will it improve the performance and reduce the run time ?
It would not affect if you are running a single update or a series of small updates. It really affects you when you are doing batch processing. The reason for this is the way hibernate implements dirty checking. Once you load an object in memory and do not evict it, the hibernate session keeps track of it in case if it was changed. So, any time you perform a query, the session iterates over all objects in the session checking dirtiness and flushes any dirty objects to the database. It does this to ensure that all state changes that might affect the query are present in the database before issuing the query to it. That’s fine when you have only a few objects in session, but when you have thousands and are performing thousands of queries, it becomes a real drain on performance.
Tim fennel has made this interesting observation about the FlushMode.NEVER in his blog here.
Spring provides a similar way to annotate methods @Transactional(readOnly=true) in Spring which internally has the same affect.
Hibernate is one of the most popular ORM frameworks.
A new test on hibernate hibernate interview questions , has been added at Skill-Guru. This test has questions on code level to challenge your knowledge and to test how deeply you understand hibernate. The problems outlined in this test are the ones which you would have encountered in day to day working with hibernate.
Some of the Questions in this test are
The second level caching has been enabled in hibernate but the tests show that the select queries still hit the database. What could be wrong here ?
Which of the following is true for composite primary keys in hibernate?
What is true for session.flush() in hiberante ?
I have a table which does not define any primary key. How can this table be mapped in hibernate
In which of the scenarios outlined below , can session.merge() can be used ?
What is the first level caching in hibernate ?
Skill-guru has some very good tests on hibernate
Hibernate interview questions 1
Hibernate interview questions 2
Any time you want Hibernate to manage the persistence of your JavaBeans, you must first initiate a transaction, which is just a simple method call on the Hibernate Session.
Once you being a transaction, you can start associating your POJOs and JavaBeans with the Hibernate Session. If you don’t initiate a transaction, you’ll get a runtime exception telling you about no transactional context being in existence, and at all costs, we want to avoid runtime exceptions.
Now, the really cool thing about Hibernate is the fact that once a transaction has been started, all you have to do is associate an instance with the Session, and then Hibernate will take care of fully managing the persistent state of that instance, right up to and including the point where you commit the transaction. When you finally commit the transaction, the state of all of the POJO’s that have been associated with the Hibernate Session will be saved to the database. Read more…
In our earlier post we had covered what exactly saveorUpdate in hibernate does.
Developers that are new to Hibernate constantly calling the saveOrUpdate method whenever a set of changes have been made to a POJO. This isn’t necessary. You only have to associate an instance with the Hibernate Session once within the scope of a transaction. From that point on, you can do whatever you want to your JavaBean instances. Hibernate will persist the final state of your instance when the current transaction is finally committed.
The following piece of code needlessly calls the saveOrUpdate method after instance variables have been updated. This is totally unnecessary, as the User instance was already associated with the Hibernate Session through the original call to saveOrUpdate. Read more…
In this post we will talk about how to integrate hibernate Search into your existing Spring, JPA and Hibernate application and some of the challenges we faced.
We have a web application using Hibernate (with JPA ) and Spring. This application relies on Spring for transaction, bean initialization / injection etc. EntityManager, transaction are configured in application.xml file. When integrating Hibernate search in such an application one might face problems. In this post I am sharing some problems I faced during integration and the solutions for same.
Entitymanager configuration in my application.xml
<property name=”location” value=”classpath:myproperties.properties”/>