Igor Trofimov wrote:
> iT>>Эта величина зависит не от длительности сессии, а от количества
> загруженных в сессию экземпляров.
> C>Это я и имею в виду.
> Вы имеете в виду, что сессия не должна загружать много объектов? Не
> слишком ли много ограничений? Логике лучше знать, сколько и каких данных
> ей нужно загрузить, обработать и сохранить. И при этом этой логике не
> хочется часто вспоминать об NHibernate и оптимизировать свои действия
> для него.
Обычный цикл загрузить_объект/поменять_объект/сохранить_объект на
Hibernate работает без проблем. Сессии в сотни тысяч объектов flush'атся
почти мгновенно.

А если у вас там миллионы объектов, да еще и с десятками запросов в
секунду, то надо уже думать что оптимизировать.

> C>Ставишь interceptor (реализуешь org.hibernate.Interceptor), в нем
> переопределяешь метод findDirty — и усе. Вчера как раз пришлось так сделать
> C>Еще можно пошаманить с AbstractFlushingEventListener — унаследоваться
> от него, и добавить свою логику. Тогда вообще можно граф не оббегать.
> Да, так и живем. Это называется "тупо используешь — и оно очень быстро
> работает"?
В обычных условиях — да.

> C>Кстати, хорошей идеей тут было бы использование модификации байт-кода.
> В Hibernate оно уже есть для поддержки lazy properties — надо еще
> добавить, чтобы оно умело помечать объекты при их изменении. Можешь
> написать им feature request.
> Спасибо, я лучше как-нибудь так... Хибернейтовские прокси, кстати, у
> меня нормально не работают — вешают отладчик при попытке просмотра объекта.
Это вопросы к отладчику. IDEA/Eclipse замечательно работают.

У тебя, скорее всего, он пытается инициализироваться при чтении полей —
и отладчику плохеет.