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.
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.
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?
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.
Joined: Feb 05, 2007
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.
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.
Customer surveys are for companies who didn't pay proper attention to begin with.