Как постараться не блокировать EDT с ленивой загрузкой JPA в настольных приложениях Swing
Я борюсь с реальным использованием JPA (Будьте в спящем режиме, EclipseLink, и т.д.) в настольном приложении Swing.
JPA походит на прекрасную идею, но полагается на ленивую загрузку для эффективности. Ленивая загрузка требует, чтобы менеджер по объекту существовал в течение времени жизни компонентов сущности, и не предлагает управления тем, какой поток используется для загрузки или любого способа сделать загрузку в фоновом режиме, в то время как EDT продолжает другие вещи. Доступ к свойству, которое, оказывается, лениво загружается на EDT, заблокирует UI Вашего приложения на доступе к базе данных даже без возможности установить занятый курсор. Если приложение работает на Wi-Fi/3G или медленном Интернете, который может сделать, это быть похожим на него отказало.
Для предотвращения ленивой загрузки, останавливающей EDT, я должен работать с отдельными объектами. Затем если мне на самом деле нужно значение ленивого свойства все мои компоненты (даже те, которые должны, предположительно, смочь не знать о базе данных), должны быть готовы обработать ленивые исключения загрузки или использовать PersistenceUtil для тестирования на состояние свойства. Они должны отправить объекты назад рабочему потоку базы данных, который будет объединен и загрузит свойства прежде чем быть отсоединенным, и возвратились снова.
Для создания этого эффективным мои компоненты должны знать заранее, какие свойства боба будут требоваться.
Так, Вы будете видеть, что все эти солнечные учебные руководства демонстрируют, как сделать на скорую руку простое Приложение типа CRUD на Платформе NetBeans, Eclipse RCP, Платформа Приложения Swing, и т.д. с помощью JPA, но в действительности продемонстрированные подходы нарушают основные методы Swing (не блокируйте EDT), и абсолютно нежизнеспособны в реальном мире.
(Больше детали в рецензии здесь: http://soapyfrogs.blogspot.com/2010/07/jpa-and-hibernateeclipselinkopenjpaetc.html)
Существуют некоторые связанные вопросы с несколько полезными ответами, но ни один из них действительно не покрывает блокирование EDT / ленивая загрузка / проблемы управления времени жизни менеджера по объекту вместе.
Ленивые/Нетерпеливые стратегии загрузки в случаях дистанционной работы (JPA)
Как другие решают это? Я рявкаю неправильное дерево путем попытки использовать JPA в настольном приложении? Или есть ли очевидные решения, которые я пропускаю? Как Вы стараетесь не блокировать EDT и сохранять Ваше приложение быстро реагирующим при использовании JPA для прозрачного доступа к базе данных?
2 ответа
Я столкнулся с такой же проблемой. Моим решением было отключение ленивой загрузки и обеспечение полной инициализации всех сущностей перед их возвратом из уровня базы данных. Следствием этого является то, что вам нужно тщательно разрабатывать сущности, чтобы их можно было загружать по частям. Вы должны ограничить количество ассоциаций x-to-many, в противном случае вы в конечном итоге будете извлекать половину базы данных при каждой выборке.
Я не знаю, является ли это лучшим решением, но оно работает. JPA был разработан в первую очередь для приложений без статических запросов-ответов. Он все еще очень полезен в приложении Swing с состоянием - он делает вашу программу переносимой для нескольких баз данных и экономит много кода с кодовыми шаблонами. Однако, вы должны быть гораздо более осторожны, используя его в этой среде.
Я использовал JPA только со встроенной базой данных, где задержка на EDT не была проблемой. В контексте JDBC я использовал SwingWorker для фоновой обработки с уведомлением GUI. Я не пробовал его с JPA, но вот тривиальный пример JDBC пример.
Дополнение: Спасибо @Ash за упоминание этой ошибки SwingWorker . Обходной путь - сборка из исходников был представлен.