• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Which one is faster

 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hibernate Vs JDBC

As comapre to time only which one is faster.
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, Hibernate does a lot more than JDBC does so probably JDBC. Mind you, Hibernate probably performs better than poorly written JDBC code. This is just conjecture though; if you want to find out write a test and see. Of course you'd never select an ORM if your only metric is performance. Hibernate (as with most ORMs) performs well enough to be useful.
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It really depends. There are definitely ways to make Hibernate run faster, like when it gets the data from cache, JDBC could not do this. Also the way that Hibernate works with batch statements and prepared statements can better utilize JDBC underneath than most people think about when they do JDBC themselves.

The big key is that if you use JDBC code, then about 30% of your code will be JDBC code, whereas with Hibernate that would be removed, you would still have your DAO code to create queries, but in general it is much easier to read, and you don't have to deal with Object arrays as result sets as you get with JDBC.
This paragraph has nothing to do with performance, just some key points.

Mark
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Guys,

just a couple of questions want to ask:

1. You talked about that hibernate automaticly batches the statement, does hibernate change the order of the statements in one single batch it forms.
I ran into the problem in EJB2.0 with weblogic. When I tried to deleted a record with a unique constraint and then insert a record with the same unique constraint in one single transaction, I got "unique constraint violation". It seems that weblogic batches the statements but changes the query order or fire them simutaneously. Does hibernate have the mechanism to stop sth like this.
2. Does hibernate do the result set cahching? or it only does object instance caching?

Thanks,
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When mapped correctly, then Hibernate will run statements in the correct order.

Hibernate stores the mapped object in its persistence context, not the ResultSet object.

Mark
 
smectite wo
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks. Mark.

To answer which one is faster.

Since most orm using java reflection to populate the data. It is slower than to manupilate the result set directly. Then again as Mark said, orm can do optimization for you.
personally, I do not htink that you need hibernate or ejb2.0/3.0 if your program has no heavy load, not distributed, and it dosn't need transaction, data concurrency and integrity.
For read-only data, I prefer ibatis.
 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by smectite wo:
Since most orm using java reflection to populate the data. It is slower than to manupilate the result set directly...For read-only data, I prefer ibatis.



Well, I am a big fan of iBatis. But it uses reflection also. The difference is that you are writing the SQL for iBatis. Hibernate generate *most* of the SQL for you in *most* cases.

I find this thread odd because Hibernate uses JDBC. So I suppose the OP's question was just worded badly. It probably should have been:

"Hibernate Vs straight JDBC"

Though I suppose that was implied and I am just overthinking it.
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"smectite wo", welcome to the JavaRanch.

We're a friendly group of people, but we do require members to have valid display names.

Display names must contain your first name, a space, then your last name. Fictitious names are not allowed.

Please edit your profile and correct your display name since accounts with invalid display names will be deleted.
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In theory, JDBC should be faster, just as in theory assembly language is faster than compiled high-level languages. And, at the micro level, both are usually true. At the macro level, however - and, more importantly, in measured studies - ORM frameworks such as Hibernate and JDO often provide much better performance. That's because, although the frameworks are running generalized performance code, it's usually not worth all the labor involved in hand-tuning low-level code, so the handwritten stuff isn't performant at the macro level.

YMMV, of course. When it really matters, it's worth setting up metrics and experimenting. Most of the time, the reduction in coding and debugging time alone makes ORM worth the effort. Especially the reduction in debugging time.
 
crispy bacon. crispy tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic