Databases
StackOverflow2013
Postsdbo
POWhat is a bulk update in the context of JPQL queries and JPA persistence context?
Body
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWhat is a bulk update in the context of JPQL queries and JPA persistence context?
    text
    copied!<p>The JPA 2.0 specification (JSR 317) says:</p> <pre><code>The persistence context is not synchronized with the result of the bulk update or delete. </code></pre> <p>Exactly <strong>what is</strong> a <em>bulk</em> update?</p> <p>In my view, there is [or rather <em>should be</em>] a difference between a "bulk update" and a "regular update". I would like to believe that a bulk update is one that update multiple entities. Thus there should be an update not categorized as "bulk", an update operation that only targets one single entity. And in this context, whether that operation updates the first-level cache or not, is quite important.</p> <p>The specification never address this issue or give a clear cut definition of the expression "bulk update". Nor can I find any other source on the topic. I tried my best to test an application managed resource-local entity manager (with EclipseLink 2.3.2.v20111125-r10461) and can confirm that the persistence context is indeed out of date even if we execute an update query that only target one single entity. Nor did the JPA provider invoke my entity listener I had attached to the test class.</p> <p>I assumed after reading the JPA 2.0 specification that this would be the case only for "bulk updates", that is, update queries that target multiple entities with affected rows being larger than 1. But with the previously described test results in mind I am beginning to think that there is no such thing as a "regular update" and all update queries <em>is</em> "bulk updates".</p> <p>Moral of the story, if that is true, is to only thrust the contents of the caches when we do <code>EntityManager#find</code>, <code>EntityManager#merge</code>, <code>EntityManager#remove</code> and JPQL select queries (<code>Query#getResultList</code> and <code>Query#getSingleResult</code>). But we should <strong>not</strong> thrust the caches if we have executed an JPQL update or delete query (<code>Query#executeUpdate</code>). It should be added for the benefit of Java EE newcomers that other application processes and direct database calls (JDBC) can invalidate the caches too. Whether this be true or not, there's another thing I cannot understand:</p> <p>What is the <strong>rationale behind this design</strong>, why shouldn't the JPA provider synchronize the persistence context and/or his second-level cache? My first guess would be performance reasons, but then again, I have no idea.</p> <p>If you know anything, give it to me!!</p>
 

Querying!

 
Guidance
An individual column

Larger individual text columns get their own page to allow for proper reading.

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