Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / May 2007

Tip: Looking for answers? Try searching our database.

Difference between commit and flush in Hibernate

Thread view: 
santax - 28 May 2007 01:43 GMT
Hi
  Could you please tell me the difference between commit(method of
Session) and flush(method of Transaction) in Hibernate?
 I read the book "Java Persistence with hibernate" which reference
to  DAO Pattern for JDK1.5.
 The main interface of the pattern is GenericDAO as below:

 public interface GenericDAO<T, ID extends Serializable> {
        T findById(ID id, boolean lock);
        List<T> findAll();
        List<T> findByExample(T exampleInstance,
        String... excludeProperty);
        T makePersistent(T entity);
        void makeTransient(T entity);
        void flush();
        void clear();
}

what me me puzzled is why it has no method commit? And when should I
call the method flush and when shuold I commit the transaction if I
use this pattern?
Thanks.
Arne Vajhøj - 28 May 2007 03:02 GMT
>    Could you please tell me the difference between commit(method of
> Session) and flush(method of Transaction) in Hibernate?

It is my understanding that flush causes Hibernate to execute
SQL statements via JDBC while commit end up as a database
commit. Two completely different things.

I have read that one should use FlushMode.AUTO and never care
about flush, but my experience with Hibernate is not sufficient
to comment on whether that is good or bad advice.

>   I read the book "Java Persistence with hibernate" which reference
> to  DAO Pattern for JDK1.5.
[quoted text clipped - 14 lines]
> call the method flush and when shuold I commit the transaction if I
> use this pattern?

I have not read the book, so it is hard for me to say.

But it makes sense to me that commit is not tied to a specific
DAO, because a transaction will often be covering multiple
types of DAO's.

And when you call commit should be determined by your
business logic.

Arne
santax - 28 May 2007 03:26 GMT
> >    Could you please tell me the difference between commit(method of
> > Session) and flush(method of Transaction) in Hibernate?
>
> It is my understanding that flush causes Hibernate to execute
> SQL statements via JDBC while commit end up as a database
> commit. Two completely different things.

Can I simplely understande the difference as below:
1 flush execute the sql
2 commit close the connection

> I have read that one should use FlushMode.AUTO and never care
> about flush, but my experience with Hibernate is not sufficient
[quoted text clipped - 27 lines]
> And when you call commit should be determined by your
> business logic.
So, I should call the method "commit" in business layer but not in
persistence layer, is that right?

> Arne
Thanks.
Lew - 28 May 2007 05:36 GMT
Arne Vajhøj <a...@vajhoej.dk> wrote:
>> It is my understanding that flush causes Hibernate to execute
>> SQL statements via JDBC while commit end up as a database
>> commit. Two completely different things.

> Can I simplely understande the difference as below:
> 1 flush execute the sql
> 2 commit close the connection

A database commit does not close the connection.

I don't know about a Hibernate commit, but there was nothing in Arne's answer
to hint that it closes the connection.

Signature

Lew

Arne Vajhøj - 28 May 2007 15:41 GMT
>>>    Could you please tell me the difference between commit(method of
>>> Session) and flush(method of Transaction) in Hibernate?
[quoted text clipped - 4 lines]
> Can I simplely understande the difference as below:
> 1 flush execute the sql

Yes.

> 2 commit close the connection

No. Commit commits the transaction (as the method name indicates).

>> And when you call commit should be determined by your
>> business logic.
> So, I should call the method "commit" in business layer but not in
> persistence layer, is that right?

Depends on your application design, but in most cases that will
be the correct place to do it. Only the business layer knows
if all changes that belongs to the transaction has been done
and whether it should be a commit or a rollback.

Arne
santax - 29 May 2007 02:34 GMT
> >>>    Could you please tell me the difference between commit(method of
> >>> Session) and flush(method of Transaction) in Hibernate?
[quoted text clipped - 22 lines]
>
> Arne

OK,Thanks a lot.
steen - 28 May 2007 11:51 GMT
>    Could you please tell me the difference between commit(method of
> Session) and flush(method of Transaction) in Hibernate?

The difference between flush and commit are :

- 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, check http://www.hibernate.org/hib_docs/v3/api/org/hibernate/FlushMode.html
for further details on which flush mode is the right one for you.

/Steen


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.