“Никакая строка с данным идентификатором не существует”, хотя он ДЕЙСТВИТЕЛЬНО существует

Я использую, в спящем режиме и получение

Исключение в потоке "основной" org.hibernate. ObjectNotFoundException: Никакая строка с данным идентификатором не существует: [#271]

То, что является довольно странным об этой ошибке, что объект с данным идентификатором существует в базе данных. Я вставил проблематичную запись в другое выполнение приложения. Если я получаю доступ к нему в том же выполнении (т.е. то же в спящем режиме сессия), кажется, нет никаких проблем, получающих данные.

Просто, потому что это мог быть отказ отображения:

public class ProblemClass implements Persistent {
  @ManyToOne(optional = false)
  private MyDbObject myDbObject;
}
public class MyDbObject implements Persistent {
  @OneToMany(mappedBy = "myDbObject")
  private List<ProblemClass> problemClasses;
  @ManyToOne(optional = false)
  private ThirdClass thirdClass;
}

У меня нет абсолютно никакой подсказки даже там, где посмотреть на. Любые подсказки высоко ценятся!

Просто для уточнения: данные были вставлены в другое ВЫПОЛНЕНИЕ приложения. Это находится определенно в базе данных, поскольку я вижу его через SQL-запрос после завершенного приложения. И после этого, т.е. при запущении приложения снова, я получаю ошибку в ПЕРВОМ запросе базы данных - никакое удаление, никакой включенный откат.

Дополнение: Поскольку это спросили, вот код для выборки данных:

public List<ProblemClass> getProblemClasses() {
    Query query = session.createQuery("from ProblemClass");
    return query.list();
}

И только заставить его завершиться, вот общий код для вставки его (перед выборкой в другом ВЫПОЛНЕНИИ приложения):

public void save(Persistent persistent) {
    session.saveOrUpdate(persistent);
}
26
задан Rubens Mariuzzo 7 September 2015 в 21:00
поделиться

3 ответа

Эврика, я нашел!

Проблема заключалась в следующем:

Данные в таблице ThirdClass не сохранялись правильно. Поскольку на эти данные была сделана ссылка из MyDbObject через

optional = false

, Hibernate произвел внутреннее соединение, возвращая таким образом пустой результат для соединения. Поскольку данные были там, если выполнялись в одном сеансе (я думаю, в кеше), это не создавало проблем.

MySQL не обеспечивает целостность внешнего ключа, поэтому не жалуется на вставку поврежденных данных.

Решение: optional = true или правильная вставка данных.

24
ответ дан 28 November 2019 в 07:40
поделиться

Возможные причины:

  1. Строка была вставлена ​​первым сеансом, но транзакция не была зафиксирована, когда второй сеанс попытался получить к ней доступ.
  2. Первый сеанс по какой-то причине откатывается.
5
ответ дан 28 November 2019 в 07:40
поделиться

Похоже, вставка транзакции откатывается

2
ответ дан 28 November 2019 в 07:40
поделиться
Другие вопросы по тегам:

Похожие вопросы: