Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>To understand this peculiar behavior of hibernate, it is important to understand a few hibernate concepts - </p> <p><strong>Hibernate Object States</strong> </p> <blockquote> <p>Transient - An object is in transient status if it has been instantiated and is still not associated with a Hibernate session.</p> <p>Persistent - A persistent instance has a representation in the database and an identifier value. It might just have been saved or loaded, however, it is by definition in the scope of a Session.</p> <p>Detached - A detached instance is an object that has been persistent, but its Session has been closed.</p> </blockquote> <p><a href="http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/objectstate.html#objectstate-overview" rel="nofollow noreferrer">http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/objectstate.html#objectstate-overview</a></p> <p><strong>Transaction Write-Behind</strong></p> <p>The next thing to understand is 'Transaction Write behind'. When objects attached to a hibernate session are modified they are not immediately propagated to the database. Hibernate does this for at least two different reasons. </p> <blockquote> <ul> <li>To perform batch inserts and updates.</li> <li>To propagate only the last change. If an object is updated more than once, it still fires only one update statement.</li> </ul> </blockquote> <p><a href="http://learningviacode.blogspot.com/2012/02/write-behind-technique-in-hibernate.html" rel="nofollow noreferrer">http://learningviacode.blogspot.com/2012/02/write-behind-technique-in-hibernate.html</a></p> <p><strong>First Level Cache</strong> </p> <p>Hibernate has something called 'First Level Cache'. Whenever you pass an object to <code>save()</code>, <code>update()</code> or <code>saveOrUpdate()</code>, and whenever you retrieve an object using <code>load()</code>, <code>get()</code>, <code>list()</code>, <code>iterate()</code> or <code>scroll()</code>, that object is added to the internal cache of the Session. This is where it tracks changes to various objects.</p> <p><strong>Hibernate Intercepters and Object Lifecycle Listeners -</strong> </p> <p>The Interceptor interface and listener callbacks from the session to the application, allow the application to inspect and/or manipulate properties of a persistent object before it is saved, updated, deleted or loaded. <a href="http://docs.jboss.org/hibernate/orm/4.0/hem/en-US/html/listeners.html#d0e3069" rel="nofollow noreferrer">http://docs.jboss.org/hibernate/orm/4.0/hem/en-US/html/listeners.html#d0e3069</a></p> <hr> <p><strong>This section Updated</strong> </p> <p><strong>Cascading</strong></p> <p>Hibernate allows applications to define cascade relationships between associations. For example, <code>'cascade-delete'</code> from parent to child association will result in deletion of all children when a parent is deleted.</p> <p><strong>So, why are these important.</strong> </p> <p>To be able to do transaction write-behind, to be able to track multiple changes to objects (object graphs) and to be able to execute lifecycle callbacks hibernate needs to know whether the object is <code>transient/detached</code> and it needs to have the object in it's first level cache before it makes any changes to the underlying object and associated relationships.</p> <p>That's why hibernate <strong>(sometimes)</strong> issues a <code>'SELECT'</code> statement to load the object (if it's not already loaded) in to it's first level cache before it makes changes to it. </p> <p><strong>Why does hibernate issue the 'SELECT' statement only sometimes?</strong></p> <p>Hibernate issues a <code>'SELECT'</code> statement to determine what state the object is in. If the select statement returns an object, the object is in <code>detached</code> state and if it does not return an object, the object is in <code>transient</code> state. </p> <p><strong>Coming to your scenario</strong> - </p> <p><strong>Delete</strong> - The 'Delete' issued a SELECT statement because hibernate needs to know if the object exists in the database or not. If the object exists in the database, hibernate considers it as <code>detached</code> and then re-attches it to the session and processes delete lifecycle. </p> <p><strong>Update</strong> - Since you are explicitly calling <code>'Update'</code> instead of <code>'SaveOrUpdate'</code>, hibernate blindly assumes that the object is in <code>detached</code> state, re-attaches the given object to the session first level cache and processes the update lifecycle. If it turns out that the object does not exist in the database contrary to hibernate's assumption, an exception is thrown when session flushes.</p> <p><strong>SaveOrUpdate</strong> - If you call <code>'SaveOrUpdate'</code>, hibernate has to determine the state of the object, so it uses a SELECT statement to determine if the object is in <code>Transient/Detached</code> state. If the object is in <code>transient</code> state, it processes the <code>'insert'</code> lifecycle and if the object is in <code>detached</code> state, it processes the <code>'Update'</code> lifecycle. </p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload