Типичный жизненный цикл объекта Hibernate в веб-приложении -?

Question

Опишите, пожалуйста, типичный жизненный цикл объекта Hibernate (который отображается в таблицу БД) в веб-приложении. Предположим, вы создаете новый экземпляр объекта и сохраняете его в БД. Но в течение жизни приложения вы будете работать с отдельным объектом и, наконец, Вам необходимо обновить его в базе данных, например, при выходе. Как это выглядит с зимней спячкой и весной?

p.s. Могут ли транзакции и сеансы жить между переходами сервлета? Чтобы мы открыли 1 сессию и использовали ее во всех сервлетах без необходимости ее повторного открытия?

Я постараюсь привести описательный пример. Предположим, что при запуске приложения создается запись в журнале. это можно сделать сразу, Журнал log = новый журнал (...), а затем что-то вроде save (log) - журнал соответствует таблице LOG.

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

и после второго шага мы можем добавить что-то в объект журнала, например, коллекцию:

// теперь у нас есть отслеживание того, что выбрал пользователь: Set thisUserChoice, // чтобы мы могли обновить постоянный объект, теперь у нас есть новые данные! // log.userChoices = thisUserChoice.

Здесь возникает природа моего вопроса. Как мы должны справиться с этим, если мы хотим обновлять базу данных при получении новых данных от пользователя?

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

В Hibernate мы также можем загрузить объект по его идентификатору.

Но ЭТО ПУТЬ? НИЧЕГО ЛУЧШЕ?

Answer 1

Вы можете сделать все за один сеанс. Но это все равно что делать все в одном классе. Это может иметь смысл с точки зрения начинающего, но на практике никто так не делает.

В веб-приложении обычно можно ожидать одновременного запуска нескольких потоков, каждый из которых имеет дело с отдельным пользователем. Каждый поток обычно имеет отдельный сеанс, и сеанс будет иметь только управляемые экземпляры объектов, которые фактически нужны этому пользователю. Дело не в том, что вы можете полностью игнорировать параллелизм в своем собственном коде, но полезно иметь помощь hibernate. Если бы вы делали все за один сеанс, вам пришлось бы выполнять все управление параллелизмом самостоятельно.

Hibernate также может управлять параллелизмом, если несколько серверов приложений взаимодействуют с одной базой данных. В этом случае отдельные JVM не могут использовать один и тот же сеанс ...

Жизненный цикл описан в документации hibernate (которую, я уверен, вы видели).

Когда бы ни поступал запрос от веб-клиента на сервер, первое, что вы должны сделать, это загрузить соответствующие объекты (см. Раздел 10.3), чтобы у вас были постоянные, а не отсоединенные объекты, с которыми нужно иметь дело. Затем вы делаете все необходимые операции. Когда сеанс закрывается (т. Е. Когда сервер возвращает ответ клиенту), он записывает любые обновления в базу данных. Или, если ваша операция предполагает создание новых сущностей, вам придется создавать временные (с new), а затем вызывать persist () или save () (см. Раздел 10.2). Это приведет к созданию управляемого объекта - вы можете внести в него больше изменений, и Hibernate запишет эти изменения после закрытия сеанса.

Я стараюсь избегать использования отдельных объектов. Но если мне придется (возможно, они хранятся в session пользователя), то всякий раз, когда их может понадобиться сохранить в базе данных, вам придется использовать update () (см. Раздел 10.6). Это преобразует его в управляемый объект, поэтому сеанс сохранит все изменения в базе данных, когда она будет закрыта.

Spring упрощает создание нового сеанса для каждого запроса. Обычно вы указываете Spring создать sessionFactory, и тогда каждому запросу будет предоставлен собственный сеанс. Ищите «учебник по hibernate», и вы найдете несколько примеров.

Answer 2

http://scbcd.blogspot.com/2007/01/hibernate-persistence-lifecycle.html Это объясняет временные, постоянные объекты.

Также взгляните на интерфейс жизненного цикла , чтобы узнать, что делает Hibernate (и он предоставляет хуки на всех этапах, чтобы пользователь мог что-то сделать)