Один сеанс. Начните транзакцию, когда вам нужно выполнить ряд операций (например, обновить данные после диалогового окна OK), зафиксировать tx в конце. Хотя соединение постоянно открыто (поскольку это один и тот же сеанс), и поэтому все возможности для кэширования могут использоваться как Hib, так и RDBMS.
Также может быть хорошей идеей реализовать прозрачное повторное открытие сеанса в случае, если соединение оборвалось - пользователи, как правило, оставляют приложения открытыми в течение продолжительных периодов времени, и они должны продолжать работать в понедельник, даже если сервер БД был перезагрузился в выходные.
Обновление
Йенс Шаудер указал причину использования нескольких сеансов: частичное (нежелательное) обновление сеанса. Ну, это сводится к тому, как вы используете Hibernate.
Предположим, у нас открыты два диалоговых окна (как в примере с блогом Йенса). Если пользователь щелкает по радиобоксу, и мы немедленно обновляем сущность Hibernate, связанную с этим радиобоксом, то, когда пользователь нажимает кнопку Отмена, у нас возникают проблемы - сеанс уже обновлен.
Правильный способ, на мой взгляд, состоит в том, чтобы обновлять только переменные диалога (не-спящие объекты). Затем, когда пользователь нажимает кнопку ОК, мы начинаем транзакцию, объединяем обновленные объекты, фиксируем транзакцию. Никакой мусор никогда не сохраняется в сессии.
MyHibernateUtils.begin();
Settings settings = DaoSettings.load();
// update setttings here
DaoSettings.save(settings);
MyHibernateUtils.commit();
Если мы реализуем такое четкое разделение интересов, мы можем позже переключиться на несколько сеансов с простым изменением реализации MyHibernateUtils.begin ().
Что касается возможной утечки памяти, хорошо ... Transaction.commit () вызывает Session.flush (), который AFAIK также очищает кеш. Также можно вручную управлять политикой кэширования, вызывая Session.setCacheMode ().