HIBERNATE flush(), commit(), clear() methods

 

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

mode

 

 

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.

Advertisements

About rajkirpal

i am a software engineer. and i have decent knowledge about java technologies like ANDROID, Servlet, Jsp, Struts, Hibernet, Spring, J2ME, Java Script, Ajax, JQuery, CSS. Further i am Preparing Easy understandable materials/documents upon the same java technologies and developing project in core java , advanced java and j2me , ANDROID as per the requirements Also designing the web sites and logos Thank You.
This entry was posted in Hibernate. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s