Hi,

I have a conceptual query about Hibernate. This goes here.........

Which is more faster, direct database connection or database through Hibernate?
In actual we are keeping one more layer upon database when we use Hibernate and this obviously impact on performance. In my current organization most of the products are designed and developed with direct database connections or using datasource using JDBC API. We are hesitate to use Hibernate for our next projects because of performance difference......

Please justify the points clearly...

Well, intelligent, direct database access with optimized queries by someone who has intimate knowledge of SQL and the database along with SQL optimization techniques, and can cache results as effectively as Hibernate does, well, they might write an application that might be faster.

Of course, at runtime, Hibernate just does SQL calls over JDBC, so, when all is said and done, it's really the same technology. But of course, someone who can write optimized SQL can make it run faster.

Of course, I'm not sure why anyone is making development decisions based largely on performance. I've never seen an application failed to be built because when it was complete, it met 100% of the requirements but was a millisecond too slow. I've seen alot of projects fail because the technology was too difficult to understand. And I've seen alot of projects fail because developers couldn't understand the way previous developers wrote code.

Most projects fail because the development team doesn't have the skills or the knowledge to implement the task. And on top of that, the biggest cost of any application is long term maintenance, not hardware. Any good manager should know that. Technologies like Hibernate make difficult applications easier to develop, and they can be developed way faster than ones developed using straight JDBC. Also, they are much easier to maintain and manage, as the domain model can change, but no changes need to be made to JDBC or SQL calls. Furthermore, Hibernate is easy to understand. When that MIT genius that wrote all the SQL calls that nobody understands leaves the project to work for a competitor, you'll never find anyone to replace her. But if you used Hibernate, you'd have a vast sea of qualified professionals to help out.

But, if all that matters is performance, and long term cost and maintainability are not of a concern, but all means, just use straight JDBC calls. If you know what you're doing and have the skills, you might just gain several milliseconds per call. But then again, you might not.

Worth noting that Hibernate have literally years of code optimizations in place. Even with the proper skills, you'll probably face some problems which were already solved by Hibernate. So, those "several milliseconds" may not even happen :-)

I would suggest to use mainly Hibernate in your app, and use direct JDBC calls only if you find an actual bottleneck which is affecting your performance.

What most people forget, when asking this sort of question is, that Hibernate has caching at multiple layers with support for a number of caching models. Hibernates caching architecture can, and more often will, result in hibernate being faster than direct JDBC. Now this is not necessarily a fair comparison. Though caching techniques in theory are easy, in practice its hard so adding caching to direct JDBC layer is very difficult to get obsoletely right. Hence it is an engineering issue where you need to balance and consider many issues.

This is a great point. I can't tell you how many places I've worked where fresh grads look at a framework like Hibernate, and think they can do it better, and wrap the whole darn thing in extra layers that mess the whole darn thing up. I've seen people do it for Hibernate, for JSF, for Struts, for EJB...you name it, it always seems that every new guy on the development team knows better than the experts in the field that specialize in these technologies exclusively. I'm not into playing possum, but sometimes it is prudent to accept that the big players in the industry probably know what they're doing better than I do.



That's an excellent point worth emphasizing.

I think I've got the points, but when majority of business logics are performed inside db procedures and functions(in existing system). In such cases is it wise to implement Hibernate for the sake of long term maintenance of the project?

Most people who are starting from scratch choose to either define a set of sql packages and procedures and call them from the app layer, or use an ORM; and in general don't use straight jdbc with hard coded sql strings - it's a nightmare to maintain.

But in your situation I don't think you need to choose between the two if the reports etc are fairly static. If you plan on significantly changing your model etc then you may want to consider it.

It's a trade off - is the cost of re-implementing it less than the cost of the projected maintainence that will be required?

Vackar