привет.
Столкнулся с неприятной проблемой. Не понимаю с чего и откуда взялось, но частенько вываливается такого рода ошибка:

И появляется именно на createCriteria. Данные не большие и в БД их мало. Вот пример:

Возможно проблема заключается в том, что примерно 5 таких запросов выполняются друг за другом (в данном случае выбираются девайсы по тенанту, но есть также и 4 других сущности из которых выбираются данные таким же образом) ?

Где искать причину ?  
Было бы в БД записей около 100.000 другое дело, а то там всего то 40 записей ...

новые подробности. Оказывается 

отрабатывает, а вот когда делаю

выстреливает java.lang.OutOfMemoryError: Java heap space

Если делать так, то ошибки "No operations allowed after connection closed." не должно возникнуть.

И, похоже, слишком рано return делаете.

С критерием - вот так можно:



Добавлено через 4 минуты и 14 секунд


Скорее всего, потому что createCriteria - это по сути Builder, который строит запрос, а когда вызывается list() происходит извлечение самих данных.

Это сообщение отредактировал(а) Stolzen - 17.5.2011, 20:27

Stolzen, да, но эта конструкция работала полгода и всё было хорошо, а сейчас посыпались ошибки.

Добавлено через 1 минуту и 41 секунду

что значит "рано" ? Нормально я делаю 

Это сообщение отредактировал(а) Samotnik - 17.5.2011, 21:29

Вот это баг архитектуры программиста, т.е. тебя Samotnik, 
А связан он с тем, что ты пытаешься вытащить все дерево сущностей отталкиваясь от App да еще и списком их хочешь.
Давай избавляйся от Fetch.EAGER на вложенных коллекциях и убирай этот DISTINCT.
А вот теперь действительно представь, что у тебя будет, если записей станет 100 000?..

Это сообщение отредактировал(а) MisterCleric - 17.5.2011, 23:17

MisterCleric,  LAZY использовать ?

У меня давно возник этот вопрос ,не знаю сюда ее лучше вклеить или нет , 
 

С DB работаю много лет,и не только на Java, работаю напрямую через Pperare Statement (иногда cacheRowSet) , проблем которые тут (не только в этой ветке)описываються не возникало, пробовал  несколько вариатов Persistent Layer, говорят что так лучше ,

1) Что это дает? ведь все равно select(insert,update,delete) нужно писать руками , ведь если что-то меняеться в DB нужно мапить
заново. Все равно если поле написать ошибочно , скажем, From imageName вместо Image_name ошибка будет в обоих случаях,
ключи , связи все равно нужно в DB прописывать , 
 ??
2) как увидеть реальную Query, которую потом отлаживать на DB ? и наоборот Я сначала строю SQL на базе и как мне потом
   его переводить в тот же Hibernate(JPA или Eclipse link) ? не терая при этом оптимизацию, потом если выбор полей поменялся,
  то нужно менять класс, а тут у меня перекачка  ResultSet в мой объект , и какая разница? 
  Работаю примитивно никаких ArrayList , только массив (так быстрее и прыгать в нем легко) , 

Желательно конкретные примеры, типа слева один  способ  , справа другой,  , а не общии рассуждения 




 
 

Да, ставь LAZY. Это будет более правильно, но тогда тебе нужно переделывать архитектуру своего приложения, как я понял по примерам кода.
можно еще так:


Тогда все твои вложенные коллекции будут селектиться из БД в отдельном запросе. И снова тебе не нужен будет 

MisterCleric, спасибо, оставил eager, но добавил - FetchMode.SELECT

ошибки пропали     
Надеюсь навсегда