Всем привет,

Многие классы приложений постоянно сталкиваются с проблемой конкурентного апдейта, то есть синхронизацией записи. Сценарий следующий:

1) Юзер 1 открывает запись на редактирование и меняет её (для усложнения задачи допустим, что речь идет о десктоп-клиенте)
2) Юзер 2 открывает ту же запись на редактирование
3) Юзер 1 нажимает "сохранить". Запись сохраняется в базу.
4) Юзер 2 нажимает "сохранить". Запись сохраняется в базу, перетирая изменения от юзера 1.

Как решать такую проблему? Я надеялся, что JPA имеет такой механизм, но, похоже, был не прав.

Вообще, проблема эта популярная, поэтому наверняка существуют и паттерны её решения, и библиотеки с подобными возможностями. Помогите советом или ссылками.

Мои соображения: 

1) сейчас у нас за разрешение подобных конфликтов отвечает механизм stamp'ов, т.е. каждая запись имеет номер, инкрементально увеличивающийся при апдейте. Если юзер 2 хочет проапдейтить запись, но видит, что её stamp поменялся со времени загрузки, он возвращает ошибку. Но с обязанностями своими наш фреймворк справляется плохо - нетривиальные случаи использования типа кеширования или иерархической зависимости объектов (когда изменение стемпа одного объекта вызывает изменение стемпа другого) вызывают множественные side-эффекты. Хотя дело тут, во многом, в кривой реализации, а не в порочности идеи стемпов, всё таки не хочется изобретать велосипед, если он уже кем-то изобретен.
2) Другой подход - лочить запись на уровне базы, когда отдаем её кому-то на редактирование (SELECT FOR UPDATE). Но в таком случае оператор, оставивший запись залоченной перед уходом на обед, блокирует работу остальных (Stampede в свое время называл это "проблемой ковыряния в носу").

Так же. Руками.

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

Используем версионность хибернейта - по сути те самые stamp'ы и есть. Жалоб не имеем 

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

Заценим-с, спасибо.

batigoal, поделитесь успехами.
Что-нибудь получилось ?

Ищите книгу Мартина Фаулера "Архитектура корпоративных программных приложений". Там целая глава посвещена блокировкам. 

Optimistic Offline Lock
Pessimistic Offline Lock
Coarse-Grained Lock
Implicit Lock

Оно в жпа есть:
javax.persistence.Version

Нашел. книга тут.

powerOn, спасибо за совет, буду читать.