FWIW, ваша блокировка с истечением - это подход, используемый WebDAV (и реализованный в таких инструментах, как Microsoft Word, например).
Чтобы справиться с задержкой в сети, вы должны обновить свою блокировку вминимум на полпути через время жизни блокировки (например, срок действия блокировки истекает через 2 минуты, и вы обновляете ее каждую минуту).
Узнайте больше подробностей о том, как должны вести себя клиенты и серверы: http://tools.ietf.org/html/rfc4918#section-6(обратите внимание, что, например, они всегда предполагают, что сбой возможен: «клиент НЕ ДОЛЖЕН предполагать, что только из-за того, что тайм-аут не истек, блокировка все еще существует»; см. http://tools.ietf.org/html/rfc4918#section-6.6)
Другойподход заключается в том, чтобы иметь явный поток блокировки / разблокировки, а не неявный.
В качестве альтернативы, вы можете позволить нескольким пользователям одновременно обновлять клиента, используя подход «одно поле за раз»:отправьте RPC, чтобы обновить определенное поле для каждого ValueChangeEvent в этом поле.Обработка конфликтов (другой пользователь обновил поле) затем становится немного проще или может быть просто проигнорирована: если пользователь A изменил адрес клиента с «foo» на «bar», это действительно означает установить «bar» в поле, чтобы не изменять _from от «foo» на «bar», поэтому, если фактическое значение на сервере уже было обновлено пользователем B с «foo» на «baz», это не будет проблемой, пользователь A, вероятно, будет иметьпо-прежнему устанавливайте значение «bar», меняя его с «foo» или с «baz» на самом деле не имеет значения.
Используя подход для каждого поля, «неявные блокировки» (время, необходимое для редактирования и отправкиизменения на сервере) намного короче, потому что они сводятся к одному полю.
Тогда «задача» - обновить форму практически в реальном времени, когда другой пользователь сохранит изменение для отредактированного клиента;или вы можете не делать этого (не пытайтесь делать это в режиме реального времени).