Jimmy: no. Flush sends the data to the DB. If there is no transaction, then flush "commits" the changes. They're really in the DB. If there is a transaction, flush still sends the data to the DB, but DB keeps the data only in the current transaction. If you do a select from within the transaction, you'll see the changes; however, if you do a select from some other connection (and therefore, outside of the transaction) you will not see the changes.
flush ensures that what's in hibernate's memory and what's in the DB transaction are the same. commit finishes the transaction, so that what was in the transaction is now really in the DB.
Perhaps an example would futher enlighten. Consider a JDBC-only situation, no hibernate involved.
Code:
Connection con = Utilclass.getConnection();
Transaction tran = Utilclass.beginTransaction(con);
Statement st = con.createStatement("insert into TestTable (id, value) values (1, 'data')");
// At this point, nothing has been sent to the DB.
// If your computer crashes, no harm done.
// select * from TestTable will return an empty result set.
st.executeUpdate();
// At this point, you have _flushed_. select * from TestTable
// will return a result set with one row, so long as you run it
// from this method. If you ran it in a different thread, you'd
// get an empty result set.
// If your computer crashes, your DB server will notice that the
// JDBC connection has died and will automatically roll back.
tran.commit();
// At this point, your DB transaction is finished.
// select * from TestTable will return a result set with one
// row, no matter who runs it.
Utilclass.cleanup(con);
}