Краткий ответ: нет никакого «простого рецепта» для этого, ни готового решения из Hibernate или какой-либо другой среды ORM.
Длинный ответ:
Вам нужно будет выяснить, как реализовать некоторые функции, которые позволят вашему приложению эмулировать поведение блокировки базы данных для вашего "длинного разговора".
Самое главное - убедиться, что, как только пользователь начнет использовать часть информации (строку базы данных или набор объектов, в зависимости от вашего случая), эта информация не будет использоваться / обрабатываться другимипользователь.Также вам необходимо убедиться, что у вас есть некоторая политика в отношении раскрытия информации, либо когда пользователь завершает операцию, либо по прошествии определенного количества времени (вам не нужна вечная блокировка вашей информации).
Поскольку я не знаю подробностей о вашем приложении, я приведу абстрактный пример, который может послужить вдохновением для вашего случая.Конечно, это не единственное решение.
Пожалуйста, имейте в виду, что каждый шаг будет заключен в одну транзакцию, потому что, в конце концов, ваш длинный разговор будет представлять собой серию запросов в вашем веб-приложении.
Кроме того, учитывая информацию из тегов вопроса, этот ответ нацелен на решение в простом веб-приложении, которое подключается к БД.Нет «причудливой экзотики» архитектуры.
В данной таблице, которая нуждается в таком контроле, добавьте 2 столбца: один будет идентификатором пользователя, а другой меткой времени.Это будет контролировать, кто имеет «блокировку» на строке, и время, когда она была получена.
Когда пользователь начинает использовать данные, содержащиеся в строке таблицы, ваше приложение обновит строку, указав идентификатор пользователя и текущую дату / время. Это самый важный шаг , потому что вам придется правильно обращаться с параллелизмом .Если несколько пользователей пытаются установить «блокировку» в строке, ваше приложение должно признать блокировку только для только одного пользователя .На этом этапе, скорее всего, потребуется использовать блокировку базы данных в одной транзакции.Убедитесь, что этот шаг выполняется быстро и не привязан к другим операциям, поэтому блокировка базы данных не окажет большого влияния на ваше приложение.
После того, как пользователь закончил манипулировать данными, приложение может просто обнулить идентификатор пользователя и временную метку, и после этого другой пользователь сможет использовать его.
Если пользовательпо какой-то причине не выполнили задачу, вам придется применить какую-то политику «выпуска».В простых случаях простое истечение времени решит эту проблему.Если данный пользователь пытается получить блокировку для строки, которая уже имеет блокировку, ваше приложение проверит метку времени.Если время истекло, новый пользователь отменяет блокировку.Если нет, строка недоступна.
Есть и другие, более сложные сценарии.Если во время вашего процесса информация изменяется в базе данных до того, как операция полностью завершена (скажем, пользователь вносит различные изменения в информацию, и они отправляются в БД, прежде чем пользователь завершит операцию и «освободит» строку), возможно,вам придется выяснить, как осуществить откат.Может быть, нормально оставлять данные «наполовину манипулированными», а может и нет, это зависит от потребностей вашего бизнеса.
Короче говоря:
Тщательно продумайте, применим ли какой-либо из этих советов к вашему сценарию.
Надеюсь, это было полезно.