Я пытался делать подобные вещи раньше и, возможно, просто немного рассказать о своих выводах (в то время я использовал Hibernate + XFire для WS)
Я верю, что вы думаете, работает теоретически. Что вам нужно сделать, это просто сериализовать ваши управляемые объекты и отправить его клиенту. Клиент десериализует и обновляет объект (конечно, на стороне клиента, это просто обычный POJO, а не управляемые объекты) и отправляет его обратно на сервер. На этом этапе объект, полученный сервером, является просто отдельным объектом. Вы можете присоединиться к сеансу (JPA / Hibernate выполнит эту оптимистическую проверку параллелизма за вас) и сохранит вашу настойчивость.
Однако он работает нормально только для POJO. Одна из основных проблем заключается в том, что в JPA (или, в основном, во всей структуре ORM) у вас есть отношения между различными объектами. Например, Заказ будет иметь отношения с Продуктом и Учетной записью, Учетная запись будет иметь отношение к Клиенту, у Клиента будет список Адресов .... и т. Д. Это в основном хорошо, если вы манипулируете на стороне сервера из-за ленивых выборок, отношений фактически не извлекаются, пока вы не получите к нему доступ. Однако, когда вы выполняете сериализацию, это становится трудной проблемой: большинство решений для сериализации, таких как JAXB, просто рекурсивно перемещаются по всем свойствам. В результате вы ожидаете отправки только объекта Order на клиентскую сторону, но, наконец, вы отправляете огромную часть данных клиенту. Простое указание сериализатору не сериализовать некоторые свойства не сработает, поскольку, когда объект отсылается обратно и повторно подключается отсоединенный объект к сеансу, JPA / Hibernate не имеют возможности узнать, что если вы просто игнорируете отношения или вы на самом деле снимая отношения. Конечно, есть еще некоторые приемы, которые вы можете сделать, но все это делает такой подход болезненным, и он уже не элегантен.