在没有会话刷新的情况下，Hibernate标准结果会在单个事务期间更新吗？

Question

For whatever reason I have a code that in essence does something like below: it loads an instance a couple of times in a single transaction/session:

@Transactional
public void fun(final String someName){
    for(int i=0; i<10; ++i) {
        SomeClass someClass = (SomeClass) session()
                    .createCriteria(SomeClass.class)
                    .add(Restrictions.eq("name", someName))
                    .uniqueResult();

        // when not found
        if(someClass == null){
           someClass = new SomeClass();
           someClass.setName(someName); // it SHOULD be found in subsequent criteria calls
       }

        process(someClass);

        session().saveOrUpdate(someClass);
        // session.flush();                     // should it be here?
    }
}

What I am not sure about is if the results of the session().createCriteria... call change during the loop.

It's in a transaction, and if I don't find an entity - I create it (but only once).

So during the second pass, will someClass instance ALWAYS be non-null?

Answer 1

Of course you do not have to call flush, you should rarely execute flush. However the best way to proof something is with a straightforward demo, therefore I wrote a Spring Boot/Data sample and pushed it to Github . The code is equivalent to yours, and uses Hibernate 4.3.5:

@Transactional
public void createOrUpdateEmployee(String firstName, String lastName) {
  for (int i = 0; i < 10; i++) {
    Employee employee = repository.findByLastName(lastName);
    if (employee == null) {
      employee = new Employee(firstName, lastName);
      if (i > 0) {
        throw new IllegalStateException("This can never happen!");
      }
    }

    log.info(employee);

    repository.save(employee);
  }
}

The output is:

....350  ...EmployeeService      : Employee [id=0, firstName=Andreas, lastName=Kluth, hashCode=1686333223]
....396  ...EmployeeService      : Employee [id=1, firstName=Andreas, lastName=Kluth, hashCode=1686333223]
....401  ...EmployeeService      : Employee [id=1, firstName=Andreas, lastName=Kluth, hashCode=1686333223]
....403  ...EmployeeService      : Employee [id=1, firstName=Andreas, lastName=Kluth, hashCode=1686333223]
....405  ...EmployeeService      : Employee [id=1, firstName=Andreas, lastName=Kluth, hashCode=1686333223]
....407  ...EmployeeService      : Employee [id=1, firstName=Andreas, lastName=Kluth, hashCode=1686333223]
....410  ...EmployeeService      : Employee [id=1, firstName=Andreas, lastName=Kluth, hashCode=1686333223]
....412  ...EmployeeService      : Employee [id=1, firstName=Andreas, lastName=Kluth, hashCode=1686333223]
....427  ...EmployeeService      : Employee [id=1, firstName=Andreas, lastName=Kluth, hashCode=1686333223]
....429  ...EmployeeService      : Employee [id=1, firstName=Andreas, lastName=Kluth, hashCode=1686333223]

As I would have expected the entity is retrieved from the L1 cache (hashCode stays the same) and automagically flushed as the already mentioned documentation link points out: https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Web_Platform/5/html/Hibernate_Core_Reference_Guide/objectstate-flushing.html

Answer 2

Every time your code pass here:

 SomeClass someClass = (SomeClass) session()
                    .createCriteria(SomeClass.class)
                    .add(Restrictions.eq("name", someName))
                    .uniqueResult();

someClass will be null or have a reference to a registry in your database.

(I'm assuming that .add(Restrictions.eq("name", someName)) always return an unique result, otherwise it will throw an exception)

If you are creating objects that have different @ids here process(someClass); then you don't need to worry.

I normally use flush , when the database generate the id dynamically , and I need the object to reflect it right now (for example, a sequence id), so I can use it.

But in your case, I think you are providing different ids to the someClass , in the process method, so you don'need to worry about flushing.

---

EDITED

Opsss...

I didn't see this line

// it SHOULD be found in subsequent criteria calls

Assuming this, you should flush . So the database will reflect your new registry, otherwise, only at the end of the whole transaction all registries would be seen.

---

Another thing:

If this is the real code, you should do this:

SomeClass someClass = (SomeClass) session()
.createCriteria(SomeClass.class)
.add(Restrictions.eq("name", someName))
.uniqueResult();

for(int i=0; i<10; ++i) {

This way you don't need to go to the database at each iteration, assuming you are searching for the same object. (The first level cache can help here, but if you know it's the same object you are getting, just let it outside the loop).