Regarding the topic:
#1
Hibernate in Action book says:
"FlushMode.AUTO is recommended …in rare cases other modes may be required when you are working with triggers, mixing hibernate with direct JDBC or working with a buggy JDBC driver"

#2
Hibernate 3.1 reference doc says:
"From time to time the Session synchronizes its persistent state with the database. Performance will be affected if this process occurs too often. You may sometimes minimize unnecessary flushing by disabling automatic flushing"


From the above two questions may arise:

A.
from #2, it is clear disabling Session flushing may be required and may not be as rare a requirement as mentioned in #1

B.
As per API doc, it says that Transaction.commit() automatically calls flush() [default behaviour]...which means that we need to modify Flushmode to override this default behaviour...so we can expect that if we have not overridden the default behaviour then flush() method is only called when commit() is called...
However as per #2, it looks like, hibernate api does call flush() automatically for Session state synchronization other than the time when commit() is called.....So which is correct?

What does "time to time" means? Does it mean only whenever commit() is called or at other times also...if so, then when?

Additionally
========

"The process of synchronizing the memory
state with the database, usually only at the end of a unit of work, is called flushing."

Now we know commit() calls flush() internally....so what does commit do apart from flushing....surely it does NOT release the connection - this is the job of Session.close().....[perhaps digging into the Hibernate source code will reveal the answer]

When you interact with the Session, Hibernate will record all of the modifcations to persistent classes it interacts with as well as any new class which will be made persistent. When the session is flushed, Hibernate then executes the SQL to the database.

When using FlushMode.AUTO, Hibernate will flush the session under the following conditions:

1.) When the transaction commits
2.) When a query is executed
3.) When Session.flush() is called explicitly


Item #2 is what "from time to time" refers to and is something you need to watch out for. Ideally, you should execute any queries up front if possible. Hibernate flushes the session before a query is executed in order to prevent dirty reads. In regards to point A, you don't need to disable session flushing. In fact it would be a bad idea if you did because nothing would stick :)

What they mean in point #2 is if your use case does update, query, update, query, update when you could do query, query, update, update, update the latter will perform better. Even though we still flush the session, Hibernate is smart enough to know that no changes were made yet and the performance hit is far less severe.

If you're using a JTA Contextual Session, when the transaction is commited, session.flush is called and the session is closed automatically. And if I recall correctly, the Hibernate transaction does the same, but I never use that in production. Hope this helps.

Ryan-

p.s. Don't for get to rate!

Obviously transaction.commit() commit the transaction.

Well, it looks you are not taking into account what the authors mentioned in HiA as per #1...are you sure on this count?



Well I certainly agree with your above explnation...in fact I ought to have got that earlier since in retorspective when I recall what HiA says, I find that what u said makes good sense.



Well do you mean to say that session.close need not be called in a JTA situation? If so, then what about in non-managed environment(JDBC- standalone or Tomcat) - does commit only perform calling session.flush - if not then what else it does?

I think we are all aware about what happens when transaction.commit() is called, even if you don't explicitly call it :)

The orignal question was in regards to what happens at Flush time and what conditions make flushing occur.

Ryan-

FlushMode.NEVER
The Session is never flushed unless flush() is explicitly called by the application. This mode is very efficient for read only transactions.

FlushMode.COMMIT
The Session is flushed when Transaction.commit() is called.

FlushMode.AUTO
The Session is sometimes flushed before query execution in order to ensure that queries never return stale state. This is the default flush mode.

FlushMode.ALWAYS
The Session is flushed before every query. This is almost always unnecessary and inefficient.

Indeed I am. What you can do in the situations where you want to avoid a flush, you can do something like this:


So here, we can use the default of FlushMode.AUTO for most cases, and in this specific case, you we override it by suspend automatic sesison flushing while we execute the query and set it back to auto once we're done. If you set the default to NEVER, you'd have to manually flush the session at the end of each use case. It pretty much make using CMT usless. If use FlushMode.NEVER and don't ever call flush(), nothing will be in your database.

On the flip side, even when you use FlushMode.AUTO, you can still call session.flush() explicitly when needed. I have had situations where this was needed.


Yes. With a JTA Session Context, you do not need to call session.close(). Hibernate will automatically clean up all resources when the transaction commits. As for JDBC managed environments, I am 98% same is true, but I'd have to double check. I only use JDBC transactions for JUnits, not for production code. Unlike JTA however, the container doesn't know when the transaction is done, so you must make sure that you commit the transaction when your use case has completed.