About Hibenate flush(), commit() and clear() methods
The flush process synchronizes database state with session state by detecting state changes and executing SQL statements.
flush() sends SQL instructions to the database like INSERT, UPDATE etc. It will not send a COMMIT, so if you have an exception after a flush(), you can still have a complete rollback
Commit() and flush()
Commit will make the database commit
– Flushing is the process of synchronizing the underlying persistent
store with persistable state held in memory.
ie. it will update or insert into your tables in the running
transaction, but it _may_ not commit those changes (this depends on
your flush mode). When you have a persisted object and you change a
value on it, it becomes dirty and hibernate needs to flush these
changes to your persistence layer. It may do this automatically for
you or you may need to do this manually, that depends on your flush
First level cache: always active and relates to a unit of work, i.e. mostly to a service call as it is attached to the current session.
Second level cache: can be configured for certain entities. In this case, the objects are deposited in a cross-transaction cache. The key to this deposit is the primary key of the entity. The cache can be configured cluster-wide or within a JVM.
Query cache: stores the result of an HQL/EJB-QL query in a cache. For this, only the primary keys of the result objects are stored which are then loaded via second level cache. Thus the query cache works only together with the second level cache.
session is not a thread safe object – cannot be shared by multiple threads. You should always use “one session per request” or “one session per transaction”
SessionFactory.openSession() always opens a new session that you have to close once you are done with the operations.
SessionFactory.getCurrentSession() returns a session bound to a context – you don’t need to close this.
A session is opened whenever getCurrentSession() is called for the first time. This creates a brand new session if one does not exist or uses an existing one if one already exists. In tomcat this associates a session with a thread which is created using the underlying ThreadLocal object. But since Tomcat uses thread pooling it is entirely possible that a request may receive a thread with a session already associated with it, thus introducing the possibility of not even creating a brand new session. The method openSession() on the other hand creates a new session but does not attempt to associate it with a thread. But remember openSession() introduces another hitch in that it expects users to handle the closing and flushing of sessions themselves, instead of letting Hibernate do it automatically for us.