Session.save() puts a transient object into the session cache, preparing it for flushing to the DB. After Session.save(), the object becomes persistent wrt that session only.
Session.flush() writes all in-session changes to the JDBC connection; if there's no transaction, they flow on to the DB immediately. If there is a transaction, then only the current connection to the database knows about the changes that have just been made; thus other connections are protected from partial changes.
sesion.connection().commit() executes a DB commit. If the connection is in auto-commit mode, it does nothing, otherwise it's roughly equivalent to the SQL "GO" statement, or "commit tran" if there was a corresponding "begin tran".
Transaction.commit() commits the transaction. If you're using basic JDBC transactions, there's nothing much to distinguish this from connection().commit(), other than the fact that it protects you from JDBC code. However, there are more powerful kinds of transactions, and they all provide the Transaction interface, so this method can do a lot more than a simple connection().commit(). For example, if your application deals with several databases on each of several database servers, a sufficiently powerful transaction provider can encapsulate transacitons to each database into a single application transaciton.
Normally you shouldn't use session.connection(), and sesion.connection().commit() is even rarer in production code. Transaction.commit() is preferred. This allows you to replace your JDBC transactions with better ones later, and not have to change any application code.
Session.flush is frequently not needed, because the default behaviour forces a flush immediately before a commit. It is most useful when doing batch updates, where you're updating many things in a loop, all inside a single transaciton. Flushing every few dozen loops allows hibernate to rationalize its resource usage.
_________________ Code tags are your friend. Know them and use them.
|