Comments on: Hibernate hard facts part 1 http://blog.frankel.ch/hibernate-hard-facts-part-1 Nicolas Fränkel blog Wed, 28 Jul 2010 14:40:09 +0000 hourly 1 http://wordpress.org/?v=9290 By: Nicolas Frankel http://blog.frankel.ch/hibernate-hard-facts-part-1/comment-page-1#comment-549 Nicolas Frankel Thu, 11 Mar 2010 20:30:28 +0000 http://blog.frankel.ch/?p=175#comment-549 <a href="#comment-548" rel="nofollow">@Disnarda </a> Thanks, "what happens" is still a little vague but now I know the context... @Disnarda
Thanks, “what happens” is still a little vague but now I know the context…

]]> By: Disnarda http://blog.frankel.ch/hibernate-hard-facts-part-1/comment-page-1#comment-548 Disnarda Thu, 11 Mar 2010 20:25:30 +0000 http://blog.frankel.ch/?p=175#comment-548 <a href="#comment-543" rel="nofollow">@Nicolas Frankel </a> I think he is refering to another Hibernate Session, when the object is in deatached state. @Nicolas Frankel
I think he is refering to another Hibernate Session, when the object is in deatached state.

]]> By: Nicolas Frankel http://blog.frankel.ch/hibernate-hard-facts-part-1/comment-page-1#comment-543 Nicolas Frankel Thu, 04 Mar 2010 18:10:52 +0000 http://blog.frankel.ch/?p=175#comment-543 Is the Session you're refering to an HTTP session or an Hibernate Session? Could you be more specific in your question? What happens is a little vague. Is the Session you’re refering to an HTTP session or an Hibernate Session? Could you be more specific in your question? What happens is a little vague.

]]> By: btilford http://blog.frankel.ch/hibernate-hard-facts-part-1/comment-page-1#comment-542 btilford Thu, 04 Mar 2010 02:16:48 +0000 http://blog.frankel.ch/?p=175#comment-542 What happens in the (probably most common) scenario where the object is retrieved during an http request and updated in another http request? e.g. When you update you are using a different Session. What happens in the (probably most common) scenario where the object is retrieved during an http request and updated in another http request? e.g. When you update you are using a different Session.

]]> By: A Java geek » Hibernate hard facts part 2 http://blog.frankel.ch/hibernate-hard-facts-part-1/comment-page-1#comment-519 A Java geek » Hibernate hard facts part 2 Fri, 25 Dec 2009 23:50:17 +0000 http://blog.frankel.ch/?p=175#comment-519 [...] Part 1 : Updating a persistent object [...] [...] Part 1 : Updating a persistent object [...]

]]> By: A Java geek » Hibernate hard facts part 3 http://blog.frankel.ch/hibernate-hard-facts-part-1/comment-page-1#comment-518 A Java geek » Hibernate hard facts part 3 Fri, 25 Dec 2009 23:49:16 +0000 http://blog.frankel.ch/?p=175#comment-518 [...] Part 1 : Updating a persistent object [...] [...] Part 1 : Updating a persistent object [...]

]]> By: joonas http://blog.frankel.ch/hibernate-hard-facts-part-1/comment-page-1#comment-514 joonas Mon, 14 Dec 2009 15:34:03 +0000 http://blog.frankel.ch/?p=175#comment-514 Should be noted that much relies on your current flush mode (Session#getFlushMode) which many might not know of. By default flush mode ought to be FlushMode#AUTO, which means that changes to tracked entities will be flushed at latest before commit, but also before any dependant queries. Dependant queries as in queries to which your changes can cause different results -- in the above example any queries related to Persons and entities related to Person. MANUAL (previously NEVER) allows you to delay changes until you call Session#flush(). COMMIT delays (don't know if there are exceptions to this, at least javadoc doesn't specify those) until, well the transaction commit. ALWAYS delays until every query, or commit. You can control change tracking through for example Session#setReadOnly(Object, boolean), Query#setReadOnly(boolean), Criteria#setReadOnly(boolean). Spring @Transaction's readOnly applies to Hibernate through the sessions flush mode (if you use HibernateTransactionManager). Should be noted that much relies on your current flush mode (Session#getFlushMode) which many might not know of.

By default flush mode ought to be FlushMode#AUTO, which means that changes to tracked entities will be flushed at latest before commit, but also before any dependant queries. Dependant queries as in queries to which your changes can cause different results — in the above example any queries related to Persons and entities related to Person.

MANUAL (previously NEVER) allows you to delay changes until you call Session#flush().

COMMIT delays (don’t know if there are exceptions to this, at least javadoc doesn’t specify those) until, well the transaction commit.

ALWAYS delays until every query, or commit.

You can control change tracking through for example Session#setReadOnly(Object, boolean), Query#setReadOnly(boolean), Criteria#setReadOnly(boolean).

Spring @Transaction’s readOnly applies to Hibernate through the sessions flush mode (if you use HibernateTransactionManager).

]]> By: Hibernate hard facts part 2 | A Java geek http://blog.frankel.ch/hibernate-hard-facts-part-1/comment-page-1#comment-476 Hibernate hard facts part 2 | A Java geek Fri, 26 Jun 2009 22:36:48 +0000 http://blog.frankel.ch/?p=175#comment-476 [...] Part 1 : Updating a persistent object [...] [...] Part 1 : Updating a persistent object [...]

]]>