Как работать с формами которые содержат большое количество данных

#java #sql #jpa #шаблоны_проектирования

Есть ли какой то патерн для работы с формами которые содержат большое количество
данных которые не реально полностью выгрузить и базы показать пользователю на UI и
отравить во внешнюю систему. 

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


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


Вопрос очень общий. Меня интересует подход. В частности как такое реализовать с реляционной
базой данных, а ещё точнее с JPA 2.1

Что я уже пробовал:


Версионирование строк в таблице. При редактировании очередной строки в базе создается
новая запись с флагом: временная. При отмене операции - они балком удаляются, при сохранении
объекта удаляются их старые версии а флаг очищается. 
При открытии объекта, переносить данные во временное хранилище. И листать из него,
но это оказалось неприемлимо долго.
Так же были попытки создания временных таблиц.


Поделитесь своими знаниями и опытом по такой проблеме. Может быть есть паттерн или
какое нибудь общепринятое решение?
    

Ответы

Ответ 1

Описанная вами проблема решается "паттерном" Диалоги (Conversations). Пример “долгоиграющего”
диалога:


Открывается первый экран диалога. Данные, показываемые пользователю, подгружаются
в отдельной сессии Session и БД-транзакции. Пользователь может модифицировать любые
поля диалога.
После пяти минут редактирования, пользователь использует UI элемент для сохранения.
Изменения отразились в БД. Пользователь также ожидает эксклюзивного доступа к данным
на время сессии редактирования.


Хотя в описанном примере есть несколько случаев доступа к БД, с точки зрения пользователя,
данная серия шагов представляет одну единицу совершенной работы (Unit of Work). Есть
множество путей реализации этого в приложении.

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

Другой метод - использование ряда транзакций БД для реализации диалога с БД. В данном
случае, обеспечение изоляции бизнес-процессов ложится на плечи приложения. Один диалог
обычно покрывает несколько транзакций. Множественные доступы к БД могут быть атомарными,
если только одна транзакция (обычно последняя) осуществляет запись в БД. Все другие
только читают данные. Типичный путь реализации – через создание wizard-style диалога,
покрывающего несколько шагов цикла запрос/ответ. Hibernate включает в себя некоторые
возможности, позволяющие реализовать подобный функционал:


Автоматическое версионирование: Hibernate может осуществлять за вас concurrency-контроль.
Он может автоматически обнаружить, осуществлялись ли сторонние обновления данных за
время ожидания пользователя.
Отсоединенные (Detached) объекты: если вы предпочтете использовать шаблон сессия-на-запрос,
все загруженные экземпляры будут отсоединены за время ожидания пользователя. Hibernate
позволяет вам обратно подсоединить объекты и сохранить модификации. Данный паттерн
называется сессия-на-запрос-с-отсоединенными объектами. Автоматическое версионирование
используется для изоляции параллельно выполняющихся запросов.
Расширенная сессия: сессия Session может быть отсоединена от нижележащего JDBC соединения
после того, как БД транзакция будет закоммичена, и переподсоединена, когда возникнет
новый клиентский запрос. Этот паттерн называется сессия-на-диалог, делающий повторное
соединение (reattachment) объектов ненужным. Автоматическое версионирование используется
для изоляции параллельных модификаций, при этом сессия не может быть сброшена (flushed)
автоматически, только явно.


Т. е. для реализации диалогов в Hibernate можно использовать паттерны Сессия-на-запрос-с-отсоединенным-объектами
и сессия-на-диалог.

Для описания паттерна Диалог я использую Hibernate, т. к. в нём точно есть встроенная
поддержка паттера и он описан в официальной документации. Про поддержку паттерна в
JPA мне говорить сложно, но быстрое и поверхностное гугление показывает, что в JPA
паттерн реализовать можно.

Источники:


Документация разработчика Hibernate – Глава II. Транзакции и контроль многопоточности
Hibernate ORM User Guide
Implementing conversations


В последнем источнике есть примеры различных реализаций паттерна Диалог.