File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Object Relational Mapping and the fly likes hibernate Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "hibernate" Watch "hibernate" New topic
Author

hibernate

raj joe
Ranch Hand

Joined: Mar 17, 2005
Posts: 99
Is Hibernate a performance bottle neck?

I have an application where there are more than 700 concurrant users and i believe that as hibernate is object linking to DB,there would be lot of objects in the memory and would degrade the performance of the application.
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

No, in an RDBMS-backed application it is calls to the database that is the usual bottleneck. How you make these calls (via Toplink, Hibernate, iBatis, JDO etc.) is much less important in terms of performance. memory as a resource is very, very cheap, especially when compare to the cost of the development resource required to implement database accessing code for every RDBMS version your application will use.

Straight JDBC will most likely always be faster than any ORM (and straight JDBC calling Stored Procedures could be even faster), but performance should only be a driver if you have a definite requirement for a certain level of performance. Just having 700 concurrent users is a relatively useless indicator of a possibly performance problem for the DAO layer. What data access are these users performing?
[ March 09, 2006: Message edited by: Paul Sturrock ]

JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Sebastian Hennebrueder
Ranch Hand

Joined: Sep 09, 2004
Posts: 49
That SQL, Hibernate, ... behaves the same include that you can make JDBC, Hibernate, EJB applications which are slow. ;-)

Having 700 concurrent will probably imply some tuning.

Regards Sebastian


Things get always more complicated as expected.<br />Author of eBook Hibernate 3 Developer Guide by example<br />Tutorials about Hibernate, EJB, Struts, JSF <a href="http://www.laliluna.de" target="_blank" rel="nofollow">www.laliluna.de</a>
Sid Remey
Ranch Hand

Joined: Oct 02, 2005
Posts: 31
> Straight JDBC will most likely always be faster than any ORM

Could someone elaborate? I thought that one of the advantages of an ORM was the in memory caching it could do which should imply a speed increase due to an in-memory lookup as opposed to a "database over the network" lookup.

Thanks,

Sid


SCJP 1.4 (96%)
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

Originally posted by Sid Remey:
> Straight JDBC will most likely always be faster than any ORM

Could someone elaborate? I thought that one of the advantages of an ORM was the in memory caching it could do which should imply a speed increase due to an in-memory lookup as opposed to a "database over the network" lookup.

Thanks,

Sid

True, it will perform better. But only if you are accessing the same data over and over again. If you are not, then caching doesn't help.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: hibernate
 
Similar Threads
EJB vs. Hibernate
When do we have to decide for using Hibernate Search?
Can Hibernate 3.0 support MQ WAS
Persistence Framework
Startign a New Project