Spring Data (Hibernate) JPA update of individual fields not visible within transaction - spring

Question

I have an entity "Job" with a boolean flag "suspended":
#Entity
#XmlRootElement(name = "Job")
#Where(clause = "deleted=0")
public class Job {
...
#Id
#GeneratedValue(strategy = GenerationType.AUTO)
private int id;
private boolean suspended;
...
}
And a Spring CrudRepository (JPA Hibernate) is used for persistence:
#Repository
public interface JobRepository extends CrudRepository<Job, Integer>, JobStatusSupport {}
I need to update the "suspended" flag individually, without overwriting updates done to other fields in concurrent threads. So the natural thing to do seemed to be writing a method that only updates the "suspended" field:
public class JobRepositoryImpl implements JobStatusSupport {
private final static String SET_SUSPENDED = "UPDATE Job SET suspended = :suspended, modificationDate = :modificationDate WHERE id = :id";
#Override
public int setSuspended(int id, boolean suspended, Instant modificationDate) {
int updateCount = em.createQuery(SET_SUSPENDED)
.setParameter("suspended", suspended)
.setParameter("modificationDate", modificationDate)
.setParameter("id", id)
.executeUpdate();
return updateCount;
}
}
Now I have the following scenario in my code (shortened obviously, in reality this is spread out over several methods, but this example does reproduce the problem):
#Transactional
public void resumeJob(int id) {
Job jobA = jobRepository.findOne(Integer.valueOf(id));
// jobA.suspended == true
// let's set "suspended" to "false"
int updateCount = jobRepository.setSuspended(id, false, Instant.now());
// OK: updateCount is 1
Job jobB = jobRepository.findOne(Integer.valueOf(id));
// jobB.suspended == true ??? that was just set to "false, wasn't it?
}
Probably I am missing some basics about JPA/Hibernate. But still, this is extremely counterintuitive: Why is jobB.suspended still "true" although the update is successful and the data is read again "from the DB"? Why is the update of the individual field not visible within the transaction?
(As one would expect, after the transaction is complete, Job.suspended is "false" in the database and for subsequent reads.)
How would one go about this properly? How should I write code that updates individual fields so that JPA becomes aware of what was done? Do I have to look into "merge" for something as simple as this?
Being able to write our own SQL statements is crucial for our project. I am trying Spring Data JPA mainly to avoid the tedious work of writing tons of CRUD operations. But if I am already encountering such problems with this simple scenario, I am wondering whether we would not be better of using JdbcTemplate.
UPDATE: LEARNED SOMETHING ABOUT ORM
Man, was I clueless! I worked in projects where JPA was used before. But I never had to deal with it in detail (and I wonder if anybody else did).
The entire effort of writing an "update method" is futile! I have reduced this to the following:
#Transactional
public void resumeJob(int id) {
Job job = jobRepository.findOne(Integer.valueOf(id));
job.setSuspended(false);
job.setName("And Now for Something Completely Different.");
}
That's all! This updates the DB and the cache and God knows what. The #Transactional annotation alone is sufficient for persisting the changes. If the annotation is removed, the DB remains unchanged. So ORM is basically working against a cache (through "attached objects") that everybody sees. Then one hopes that people put #Transactional in the right places (not on private methods, for example...) and that the ORM machinery knows what it is doing (for example, not making cache updates visible outside of an open transaction).
Honestly, this seems a bit too magic for my taste. But now that I know what it is all about, I will give it a try. Writing gazillions of CRUD methods isn't very appealing, either.
Please comment if I got this wrong or if you have links with best practices. (I am starting to wonder if it wouldn't be best to immediately detach every object I get from the DB, defeating the entire purpose of ORM :-)
UPDATE: EntityManager#clear() Is Enough for a Quick Fix
This is definitely not the clever way to use ORM, but for the moment I can simply call clear() in the few update methods I have written. This invalidates the entire cache and the next read somewhere else in the transaction receives the updated data. Of course, the right way to do it, would be to simply modify the attached entity, i.e. "job.setSuspended(false);".
Calling flush() is not needed, probably it only becomes of interest when you want to minimize the risk of losing data in case of a system crash. I suppose that Hibernate does not immediately write completed transactions to disk?

Answer 1

It's counter-intuitive, but if you think about it, it's quite normal.
You load an entity with ID 3. Hibernate stores it in its session cache
You execute an update query. This query is almost a black box to Hibernate. It can't know which rows are affected by the changes, and you're not doing these changes by modifying the entities, but by modifying rows in the database directly. So the rows are modified, but the entity with ID 3 is left, untouched, in the session cache
You load the entity again, in the same session. So Hibernate just returns the instance that is already in the cache, and thus doesn't contain the changes.
If you want an updated entity, you have two solutions:
modify the database by modifying the entity, or
clear the cache after the update query has been made.