Преимущества использования Hibernate Callback?

Я не могу понять преимущества использования метода обратного вызова Hibernate, есть ли какие-либо преимущества или конкретный вариант использования, где мы должны это делать.

public List findRecentRequests(final int offset, final int length)
{
    List list = getHibernateTemplate().executeFind(new HibernateCallback()
    {
        public Object doInHibernate(Session session) throws HibernateException
        {
            Query q = session.createQuery(FIND_RECENT_REQUESTS);
            q.setFirstResult(offset);
            q.setMaxResults(length);
            return q.list();
        }
    });
    return list;
}

Также еще один важный вопрос заключается в том, что метод HibernateCallback закрывает сессию каждый раз после того, как запрос возвращает значения? У меня есть случай, когда я вызываю эту функцию несколько раз при каждом обновлении страницы состояния, и так будет каждый раз открывать сессию и базу запросов, или он будет хранить результаты запроса в памяти, а затем каждый раз, когда я вызываю эту функцию, результаты будут выведены из памяти.

Я прочитал (Ссылка):

spring HibernateTemplate.execute() по умолчанию закрывает все открытые сеансы после завершения. При использовании с ленивой инициализацией вы можете получить LazyInitializationException, например следующее

org.hibernate.LazyInitializationException: не удалось инициализировать прокси - нет сеанса

Любая ссылка на соответствующую часть документации будет высоко оценена.

Update:

В моем случае я использую транзакции ejb и устанавливаю его для "поддержки", и я считаю, что в этом случае, когда транзакция настроена на поддержку, она необязательна и поэтому каждый раз новый сеанс будет создан, а спящий режим будет запрашивать базу данных для получения результатов, и поэтому что у меня узкое место, будут ли правильные предположения делать?

Ответ 1

К вашему вопросу о том, зачем использовать HibernateCallback. Короткий ответ - он позволяет вам получить доступ к текущему сеансу, связанным с транзакциями, для выполнения более сложных функций гибернации. В большинстве случаев простые методы на HibernateTemplate достаточны, но иногда вам нужно спуститься к Session.

Там две части головоломки.

Первая - это область транзакции, которая определяется либо с помощью аннотаций PlatformTransactionManager/TransactionTemplate OR @Transactional. Подробнее см. В документе spring docs/google.

Во-вторых, когда вы находитесь внутри транзакции, HibernateTemplate будет взаимодействовать с текущей транзакцией, используя немного магии.

Таким образом, в транзакции будет участвовать простая операция типа hibernateTemplate.save(). Более сложный, например, ваш пример, также будет участвовать в транзакции. На самом деле почти любой метод на hTemplate будет участвовать.

Знаете ли вы на свой вопрос о том, когда сеанс закрывается

Если вы используете транзакции явно, см. первый пункт выше, тогда, когда область транзакции будет закрыта, транзакция будет зафиксирована и сеанс будет закрыт.
Без транзакций spring создает сеанс для вас каждый раз, когда вы вызываете метод HibernateTemplate и немедленно закрываете его. Это не предпочтительный подход, поскольку, если вы не делаете что-то очень просто, результаты будут отделены от сеанса, и вы получите исключения LazyInit.

Важным моментом, который следует отметить во втором случае выше, является отсутствие явной транзакции. Вы находитесь во власти режима автоматической фиксации соединения, чтобы вы могли сделать это, в обратном вызове, сохранить, сохранить, выбросить исключение. Первое сохранение MAY было совершено, без транзакции нет гарантии.

Мой совет при выполнении любых обновлений использует транзакцию.

Если все материалы транзакций новы для вас, проверьте документы spring для главы транзакции.

Ответ 2

Если вы все равно используете Spring, вы должны просто использовать декларативное управление транзакциями вокруг вашего хранилища или уровня сервиса, чтобы справиться с этим прозрачно, Реализация PlatformTransactionManager будет делать то, что подходит для данного поставщика непрерывности.

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