Hibernate и несколько потоков, синхронизировать изменения между несколькими пользователями - PullRequest
Новая
       12

Hibernate и несколько потоков, синхронизировать изменения между несколькими пользователями

2 голосов
/ 21 ноября 2011

Я использую Hibernate в приложении Eclipse RAP. У меня есть таблицы базы данных, сопоставленные с классами с Hibernate, и у этих классов есть свойства, которые выбираются лениво (если бы они не были получены лениво, то я, вероятно, в конечном итоге загрузил бы всю базу данных в память при первом запросе). Я не синхронизирую доступ к базе данных, поэтому для пользователей существует несколько Hibernate Sessions, и СУБД позволяет изолировать транзакции. Это означает, что разные экземпляры извлеченных данных будут принадлежать разным пользователям. Есть вещи, которые, если пользователь изменяет эти вещи, то я хотел бы обновить их для нескольких пользователей. В настоящее время я думал об использовании Hibernate session.refresh(object) в этих случаях для обновления данных, но я не уверен, как это повлияет на производительность при обновлении нескольких объектов или если это правильный путь.

Надеюсь, моя проблема ясна. Мой подход к проблеме в порядке, или он в корне ошибочный, или я что-то упустил? Есть ли общее решение для такого рода проблем?

Буду признателен за любые комментарии по этому поводу.

Ответы [ 2 ]

1 голос
/ 15 января 2013

Мы поддерживаем приложение, которое делает именно то, что вы пытаетесь выполнить.Да, каждый session.refresh () будет попадать в базу данных, но, поскольку все сеансы обновляют одну и ту же строку в одно и то же время, сервер БД будет отвечать на все эти запросы из памяти.

Единственное, что вывсе еще нужно решить, как распространять информацию о том, что что-то изменилось и нуждается в перезагрузке для всех других сеансов, возможно, даже для сеансов на другом хосте.

Для нашего приложения у нас около 30 пользователей на RCP и10-100 пользователей на экземплярах RAP, которые все подключаются к одному и тому же бэкэнду БД (хотя и через pgpool).Мы используем небольшую сетевую службу, к которой подключается каждая среда выполнения;когда транзакция фиксируется, приложение сообщает этой службе изменений, что «идентификатор строки X таблицы T» изменился, и затем он распространяется на все другие «изменения подписчиков», даже через JVM.

Но:убедитесь, что session.refresh () вызывается в потоке, принадлежащем этому сеансу, возможно, в потоке RAP-Display.Не вызывайте refresh () из Jobs или других не связанных между собой потоков.

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

1 голос
/ 21 ноября 2011

Общее решение

  • чтобы иметь максимально короткие транзакции
  • для привязки жизненного цикла сеанса к жизненному циклу транзакции (это значение по умолчанию: сеанс закрывается, когда транзакция фиксируется или откатывается)
  • для использования оптимистического параллелизма блокировки, чтобы избежать двух транзакций, одновременно обновляющих один и тот же объект.

Если каждая транзакция очень короткая и транзакция A обновляет некоторый объект с O на O ', то параллельная транзакция B будет видеть O только до тех пор, пока не выполнит фиксацию или откат, а любая другая транзакция, запущенная после A, увидит O', поскольку новый сеанс начинается с транзакции.

...