проблема с потерянным обновлением

Question

на моем сервере есть приложение ejb2 кластера weblogic. Эта таблица находится в БД, где другие пользователи будут одновременно создавать, обновлять и удалять.

На моих клиентских машинах полнофункциональное клиентское Java-приложение. Как я могу отправлять дельта-обновления изменений и в то же время поддерживать согласованное, всегда правильное представление таблицы? (следовательно, нет потерянного обновления, если потерянное обновление может быть обнаружено, потребуется механизм восстановления для повторной синхронизации представления)

Я думал об идее глобального номера редакции Subversion, но я не знаю, как реализовать его, так как приложение находится в кластере.

есть идеи, как это сделать?

Какие EJB-компоненты содержатся в вашем приложении?
Сессионный компонент без сохранения состояния

Как другие пользователи получают доступ к этой таблице?
Apache httpclient для JSP через сессионный компонент без сохранения состояния с подключением JDBC

Где теряется это обновление?
каждый клиент при запуске будет выполнять извлечение всей таблицы. Последующие обновления дельта-информации будут передаваться расширенному клиенту. Потерянное обновление происходит, когда клиент A пытается получить информацию, а клиент B редактирует таблицу. Поскольку редактирование клиента B состоит из дельта-информации, которая будет передана клиенту A, она может поступить быстрее. Клиент А не получил полную таблицу и, следовательно, отбрасывает дельта-информацию.

Answer 1

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

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

Использование инкрементного счетчика является одним из возможных знаков параллелизма. Идея состоит в том, чтобы добавить номер версии для ваших сущностей и увеличивать его каждый раз при сохранении.

Изображение, на котором вы читаете запись с VERSION_NUM = n. Если следующий запрос на обновление завершится неудачно:

UPDATE T 
SET VERSION_NUM = VERSION_NUM + 1 [,column_name = value ...] 
WHERE VERSION_NUM = n [AND ...]

Тогда кто-то уже обновил запись, пока вы ее редактировали.