Если в SQL выполнить

UPDATE accounts SET balance = balance - 100.00 WHERE name = 'София';

— то в рамках транзакции будут зафиксированы изменения после выполнения команды
А например, используя JpaReposity можно обновить так — получили event по id

public void update(Long eventId, String newDescription) {
    Event event = eventRepository.findById(eventId).orElseThrow(
                () -> {
                    throw new EntityNotFoundException(Event.class,
                            String.format("Entity with id=%d doesn't exist.", eventId));
                });
    event.setDescription(newDescription);
}

Как происходит синхронизация Java объекта и сущности в БД(как ORM это обеспечивает и понимает что конкретно нужно изменить)?
Т.е. это обновление происходит в какой-то момент времени между вызовом set и commit методов? Или после вызова commit?
Возможно ли отменить изменения после вызова set метода? Т.е. сделать так, чтобы эти изменения в БД не попали?
Прочитал здесь — https://jakarta.ee/specifications/persistence/3.0/jakarta-persistence-spec-3.0.html#a1955
The state of persistent entities is synchronized to the database at transaction commit. ,
но не уверен что это то что нужно

Здравствуйте, Aleksei_Lekomtsev, Вы писали:

A_L>Как происходит синхронизация Java объекта и сущности в БД(как ORM это обеспечивает и понимает что конкретно нужно изменить)?
сравнивает состояние загруженное из БД и текущее в сессии (ака персистент контекст)
полный ответ длинный это надо доки читать (а иногда и копаться в кишках ОРМ)

A_L>Т.е. это обновление происходит в какой-то момент времени между вызовом set и commit методов? Или после вызова commit?
опять же упрощая: сначала ОРМ делает flush (обновляет БД) потом транзакшн менеджер коммитит

A_L>Возможно ли отменить изменения после вызова set метода? Т.е. сделать так, чтобы эти изменения в БД не попали?
можно, например бросив исключение

A_L>Прочитал здесь — https://jakarta.ee/specifications/persistence/3.0/jakarta-persistence-spec-3.0.html#a1955
A_L>The state of persistent entities is synchronized to the database at transaction commit. ,
A_L>но не уверен что это то что нужно
я тоже не уверен что тебе нужно )

Здравствуйте, GarryIV, Вы писали:

GIV>Здравствуйте, Aleksei_Lekomtsev, Вы писали:

A_L>>Как происходит синхронизация Java объекта и сущности в БД(как ORM это обеспечивает и понимает что конкретно нужно изменить)?
GIV>сравнивает состояние загруженное из БД и текущее в сессии (ака персистент контекст)
GIV>полный ответ длинный это надо доки читать (а иногда и копаться в кишках ОРМ)

A_L>>Т.е. это обновление происходит в какой-то момент времени между вызовом set и commit методов? Или после вызова commit?
GIV>опять же упрощая: сначала ОРМ делает flush (обновляет БД) потом транзакшн менеджер коммитит

A_L>>Возможно ли отменить изменения после вызова set метода? Т.е. сделать так, чтобы эти изменения в БД не попали?
GIV>можно, например бросив исключение

A_L>>Прочитал здесь — https://jakarta.ee/specifications/persistence/3.0/jakarta-persistence-spec-3.0.html#a1955
A_L>>The state of persistent entities is synchronized to the database at transaction commit. ,
A_L>>но не уверен что это то что нужно
GIV>я тоже не уверен что тебе нужно )

Я так понял, что например в Hibernate есть First-level cache и Second-level cache — это вроде как тоже влияет

Здравствуйте, Aleksei_Lekomtsev, Вы писали:

A_L>Я так понял, что например в Hibernate есть First-level cache и Second-level cache — это вроде как тоже влияет
выше про First-level cache оно же хибернейт сессия оно же персистент контекст, Second-level cache к делу не относится.