如何避免在Swing桌面应用程序中通过JPA延迟加载阻止EDT [英] How to avoid blocking EDT with JPA lazy loading in Swing desktop apps
问题描述
我正在努力在Swing桌面应用程序中实际使用JPA(Hibernate，EclipseLink等).
I'm struggling with real-world use of JPA (Hibernate, EclipseLink, etc) in a Swing desktop application.
JPA似乎是个好主意，但要依靠延迟加载来提高效率.延迟加载要求在实体bean的生存期内存在实体管理器，并且在EDT进行其他操作时，无法控制使用哪个线程进行加载或在后台进行任何方式的加载.访问恰好是在EDT上延迟加载的属性，将阻止您的应用程序的UI访问数据库，甚至没有机会设置繁忙的游标.如果该应用程序在wifi/3G或慢速的Internet上运行，可能会使它看起来像崩溃了.
JPA seems like a great idea, but relies on lazy loading for efficiency. Lazy loading requires the entity manager exist for the lifetime of the entity beans, and offers no control over what thread is used for loading or any way to do the loading in the background while the EDT gets on with other things. Accessing a property that happens to be lazily loaded on the EDT will block your app's UI on database access, without even the opportunity to set a busy cursor. If the app is running on wifi/3G or slow Internet that can make it look like it has crashed.
为避免延迟加载使EDT停顿，我必须使用分离的实体.然后，如果我实际上需要一个惰性属性的值，则必须准备好我的所有组件(甚至那些本应能够不知道数据库的组件)以处理惰性加载异常或使用PersistenceUtil来测试属性状态.他们必须将实体分派回数据库工作线程进行合并，并在分离和再次返回之前加载属性.
To avoid lazy loading stalling the EDT I have to work with detached entities. Then, if I actually need the value of a lazy property all my components (even those that should supposedly be able to be unaware of the database) have to be prepared to handle lazy loading exceptions or use PersistenceUtil to test for property state. They have to dispatch entities back to the database worker thread to be merged and have properties loaded before being detached and returned again.
要使其高效，我的组件需要预先知道 所需的bean属性.
To make that efficient, my components need to know in advance what properties of a bean will be required.
因此，您将看到所有这些令人眼花shiny乱的教程，它们演示了如何使用JPA在NetBeans平台，Eclipse RCP，Swing App Framework等上鞭打一个简单的CRUD应用程序，但实际上，所展示的方法违反了基本的Swing做法(请参见不会阻止EDT)，并且在现实世界中是完全不可行的.
So, you'll see all these shiny tutorials demonstrating how to whip up a simple CRUD app on the NetBeans Platform, Eclipse RCP, Swing App Framework, etc using JPA, but in reality the approaches demonstrated violate basic Swing practices (don't block the EDT) and are completely non-viable in the real world.
(此处有更多详细信息，请参见: http://soapyfrogs.blogspot.com/2010/07/jpa-and-hibernateeclipselinkopenjpaetc.html )
( More detail in write-up here: http://soapyfrogs.blogspot.com/2010/07/jpa-and-hibernateeclipselinkopenjpaetc.html )
有些相关问题的回答有所帮助，但没有一个真正涵盖edt阻止/延迟加载/实体管理器生命周期管理问题.
There are some related questions with somewhat helpful responses, but none of them really cover the edt blocking / lazy loading / entity manager lifetime management issues together.
其他人如何解决这个问题?我是否试图通过在桌面应用程序中使用JPA来树错了树?还是我缺少明显的解决方案?使用JPA进行透明数据库访问时，如何避免阻塞EDT并保持应用程序响应速度?
How are others solving this? Am I barking the wrong tree by trying to use JPA in a desktop app? Or are there obvious solutions I'm missing? How are you avoiding blocking the EDT and keeping your app responsive while using JPA for transparent database access?
推荐答案
我遇到了同样的问题.我的解决方案是禁用延迟加载，并确保所有实体在从数据库层返回之前都已完全初始化.这样做的含义是，您需要仔细设计实体，以便可以大块加载它们.您必须限制x对多关联的数量，否则最终将在每次提取时检索一半的数据库.
I have encountered the same problem. My solution was to disable lazy loading and ensure that all entities are fully initialised before they are returned from the database layer. The implications of this is that you need to carefully design your entities so that they can be loaded in chunks. You have to limit the number of x-to-many associations, otherwise you end up retrieving half the database on every fetch.
我不知道这是否是最好的解决方案，但它确实有效. JPA主要设计用于请求响应无状态应用程序.它在有状态的Swing应用中仍然非常有用-它使您的程序可移植到多个数据库中，并节省了大量样板代码.但是，您必须在该环境中使用时更加小心.
I do not know if this is the best solution but it does work. JPA has been designed primarily for a request-response stateless app. It is still very useful in a stateful Swing app - it makes your program portable to multiple databases and saves a lot of boilerplate code. However, you have to be much more careful using it in that environment.
这篇关于如何避免在Swing桌面应用程序中通过JPA延迟加载阻止EDT的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
