without hibernate, to update a record, only need to send one update statement to database:
update tablename set col2 = 'abc' where col1 = '123'.
however, with hibernate, I have to load object first,then update:
obj = (Obj)session.load(tableNm.class,123);
obj.setCol2 = "abc";
session.update(obj);

this need 2 statement :
1. select * from tablename where where col1 = '123'.
2. update tablename set col2 = 'abc' where col1 = '123'.

if this is true, then further more, to update multiple record, we need a loop to load and update record one by one. however, with native SQL, on one update setament like:
update tablename set col2 = 'abc' where col1 in (...).
is neccssary.

is hibernate provide a poor solution regarding database performance?
size=18][/size]

True, but, in a real applications, often is not that simple (you have to worry about, for example, optimistic concurrency, master-detail relationships, identity generation, business rules constrains, etc).




Thanks to that, Hibernate can compare the internal snapshots of your data, and see if there could be conflicting changes, without having to use database locks, that IMHO are not as scalable. Also by working with objects, you can set multiple master-detail relationships without worrying about having to issue the INSERTS and UPDATES in a particular order (Hibernate does that automatically). Also you can configure validation before saving you objects so that the comply with your particular bussines rules.



Exactly, and there are cases when the best solution is to send a direct update to the database (if you need to modify lots of records, and you are not that worried that your modification might break some bussines logic constraint, mess with optimistic concurrency or have master-detail implications).




It depends on the case, there are not "one solution fits all" in persistency... you have tu analize things in a case by case basis... for example, you will need to think about how the way your user is going to interact with the data affects the SQL you send to the database (and what data you need to keep in memory, in a tipicaly OLTP application, you need to show the data to the user and then allow him to modify it).

In other words, it is not that simple, you would have to provide me with an example of a bussines transaction use case with at least 3 tables and complex interaction with the user... and then you could say "in X particular case, using direct SQL is more efficient" in my experience, specially with OLTP applications, Hibernate helps creating a more mantainable, "more correct" (from concurrecny or business logic validation point of view) and more efficient solution.

Thanks luxspes,
The answer really helpful, the credit has been added for your kindly help