Why does hibernate need to save the parent when saving the child and cause a OptimisticLockException even if there no change to the parent?

It does NOT need it unless you need it. Do this:

    University universityProxy = universidyRepository.getOne(universityId);
    student.setUniversity(universityProxy);

In order to assign a University you don't have to load a University entity into the context. Because technically, you just need to save a student record with a proper foreign key (university_id). So when you have a university_id, you can create a Hibernate proxy using the repository method getOne().

---

Explanation

Hibernate is pretty complex under the hood. **When you load an entity to the context, it creates a snapshot copy of its fields and keeps track if you change any of it**. It does much more... So I guess this solution is the simplest one and it should help (unless you change the `university` object somewhere else in the scope of the same session). It's hard to say when other parts are hidden.

---

Potential issues

• wrong @OneToMany mapping

    @OneToMany(mappedBy = "student") // should be (mappedBy = "university")
    @ToString.Exclude
    private List<Student> student;

• the collection should be initialized. Hibernate uses it's own impls of collections, and you should not set fields manually. Only call methods like add() or remove(), or clear()

    private List<Student> student; // should be ... = new ArrayList<>();

*overall some places are not clear, like studentRepository.findById(student);. So if you want to have a correct answer it's better to be clear in your question.

If you enable your query logs from Hibernate, it would be worthwhile to see the queries that your ORM is performing. You'll likely realize that your ORM is doing too much.

In your application properties or config file enable hibernate.show_sql=true

I wouldn't be surprised if your single update to a Student becomes an update to a University which becomes an update to all of its containing Students. Everything gets a version bump.

ORM and entity mappings are for strategically retrieving data. They should not be used to actually define object relationships.

You'll want to visit strategies and design your entities based on how they are used in their REST endpoints.

You specified in your question that you are trying to save a Student but you're noticing that the University also gets updated along with every Student update.

Likely there would never be a time when a Student should ever update a University

Keep your entities lean!

You can structure your entity in such a way that supports this unidirectional relationship. I removed some of the annotation just to demonstrate the structure. You will want to keep in mind that when creating entities, you are writing them for how they are retrieved...

public class University {

    @Id
    private Long id;
    private String name;
    private Long auditVersion;
    @OneToMany
    private List<Student> student;
}

public class Student {

    @Id
    private Long id;
    private String name;
    private Long auditVersion;
    private Long universityId;

}

This will ensure that updates to the student remains targeted and clean. You are simply assigning a university id to the student therefore establishing that relationship.

You typically want to respect LockExceptions. Retrying upon a LockException is simply bullying your database into submission and will cause more headaches as your application scales.

You always have the option to work with lean entities and create custom response or message objects that would zip the results together.

ORMs are not to be used to create shortcuts

The performance consequence of a SELECT on an indexed/foreign key is roughly the same cost of grabbing them joined... you only introduce a little extra network latency. A second trip to the database is not always a bad idea. (Often times, this is exactly how Hibernate fetches your entities)

You won't have to write queries, but you will still need to understand the retrieval and update strategies.

You're sacrificing database performance and introducing complexity for a convenient .getChild() method. You'll find that you resolve more performance/locking issues by removing annotations, not adding them.