Добрый день, возник следующий вопрос по очень интересной задаче:
Технологии в проекте: posgreSQL - hibernate, envers 3.6.8 - spring 3.1  - zkoss 
Описание: есть некое подобие универсального визарда(карточки), в карточке происходит редактирование, создание главного объекта и логически связанных с ним объектов. Для примера: есть объект «заказчик» открывается визард(карточка), где в первой вкладке информация о заказчике(рефлексей выдернуты поля), а во второй вкладке его заказы, связь 1 ко многим и к примеру, в 3 вкладке будет добавляться или изменяться  уже некоторая информация выбранного заказа(1 к 1). Заказов будет много поэтому они получаются по странично скажем по 20 элементов на страницу.
Операция по редактированию такого объекта может быть долговременной, то есть пользователь может долго править поля заказчика, потом долго заказы, а потом и уже дополнительную информация по каждому заказу. 

Задача:  реализовать универсальный визард(карточку) для работы со всеми объектами системы. Для каждого объекта будут разные наборы закладок и определять в зависимости от того какие интерфейсы реализует объект, для разных объектов могут использоваться одинаковые закладки, ну к примеру если объекты входят в систему безопасности, то для таких объектов будет вкладка «доступ». Переключения между вкладками может быть в произвольном порядке, а не в строгом, как у настоящего визарда.

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

Дополнения: вкладки по работе с разными логически связанными объектами создаются разными программистами и независимы друг от друга, то есть они могут вынимать данные либо из базы, либо какой-то хитрый механизм в памяти.

Вариант решения: так как держать открытой сессию с бд не вариант, так как пользователь может быть много и каждый может редактировать какие-то объекты то это погубит систему, тогда остается 2 варианта либо создавать какую-то сложную структуру данных в памяти либо 3 но я его пока не вижу. 

Если делать через память, и как-то сохранять объекты которые (добавились, удалились или изменились) то кроме того, что надо вести очередь изменений,так как последовательность при сохранении в бд важна,  надо еще учитывать связанность объектов.
 
Возникающие сложности если делать через память:
1.пользователь открыл заказчика «Петю» у которого 40 заказов, перешел на страницу ему подгрузилось 20 первых заказов, он 1 добавил и 2 удалил. Затем загрузил еще 20 заказов и снова вернулся к первым 20. Так как данные сразу не вносятся в базу, а закладка независима и обращается за заказами через сервис к бд, то естественно в выборке их не будет . Не будет ни 1 добавленного и снова будет 2 удаленных на месте.
2.пользователь добавил новый заказ на 2 вкладке в карточке, перешел на вкладку 3 и создал дополнительную информацию. Снова вернулся на вкладку 2 и удалил вновь созданный заказ, так как вкладки разрабатываются независимо друг от другу, то получается в 3 вкладке доп. информация которая уже не актуальна остается висеть.  И если мы в очередь вставляем элементы которые потом необходимо сохранить в бд, то нам из очереди надо будет удалить и ново созданный объект(заказ) и зависящие от него объекты. 
3.Есть и другие сложности описал только эти.

Может кто сталкивался с подобными задачами и может подсказать как их решать или хоть дать толчок в какое-то направление иди хоть что-то, а то уже всю голову сломал) Очень жду советов. 
Заранее благодарен.

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