是 JPA + EJB 对于通过 Internet 的事务来说太慢（或太重）？
我正在开发一个独立的 java 客户端应用程序，该应用程序连接到 Glassfish v3 应用程序以进行 JPA/EJB 外观样式事务。换句话说，我的客户端应用程序不直接连接到数据库进行 CRUD，而是使用 EJB 无状态会话传输 JPA 对象。
我有一些场景，此客户端应用程序将在与 Internet 上的 VPN 连接的外部网络中使用，客户端连接为 512kbp/DSL，一个简单的查询需要很长时间，我看到流量图，当我合并在客户端应用程序中的实体中，我看到了兆字节的流量（我无法相信采购订单实体的重量怎么会超过 1 MB）。
我几乎在每个多对多关系中都有LAZY fetch，但是实体之间有很多多对一关系（但这就是JPA的巨大优势！）。
我可以做些什么来加快 JPA/EJB 服务器和远程 java 客户端之间的事务速度吗？
先感谢您。
I am developing a stand-alone java client application that connects to a Glassfish v3 application for JPA/EJB facade style transactions. In other words, my client application do not connect directly to the database to CRUD, but it transfers JPA objets using EJB stateless sessions.
I have scenarios where this client application will be used in an external network connected with a VPN over Internet with a client connection of 512kbp/DSL, and a simple query takes so much time, I'm seeing the traffic graph and when I merge a entity in the client application I see megabytes of traffic (I couldn't believe how a purchase order entity could weight more than 1 mb).
I have LAZY fetch in almost every many-to-many relationship, but I have a lot of many-to-one relationships between entities (but this is the great advantage of JPA!).
Could I do something to accelerate the the speed of transactions between JPA/EJB server and the remote java client?
Thank you in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您实际传输了多少数据？也许您发送的采购订单有一个产品，有一个模型，有一个供应商，有一组模型......等等......
您可以尝试序列化您发送到服务器的对象到文件中（使用标准 ObjectOutputStrem）并检查文件有多大。
How much data do you really transfer? Maybe the purchase order you're sending has a product, which has a model, which has a supplier, which has a set of models... and so on...
You could try serializing the object you're sending to the server into a file (using the standard ObjectOutputStrem) and check how big the file is.
RMI-IIOP 比普通 RMI 更详细一些。根据我的经验，它在传输大图时效果不佳。
到目前为止，我记得（但也许事情同时发生了变化），当您传输延迟加载的实体时，尚未加载的部分将按原样发送（代理已序列化），这意味着您无法访问它们在客户端上，因为如果不再有会话，延迟加载将不起作用。您是否在将实体发送回客户端之前急切地加载该实体？
但问题的关键在于，你所处的场景需要考虑传输数据的策略。您必须以一种不发送大图的方式设计您的应用程序；这个问题必须在应用程序的设计中得到解决。然后您可以决定仍然发送 JPA 实体或依赖数据传输对象 (DTO)。
您还可以考虑使用带有状态会话 bean 的扩展持久性上下文，这样我认为客户端上的实体仍然可以延迟加载。但我个人没用过这个，不知道效果好不好。
RMI-IIOP is a bit more verbose than plain RMI. In my experience, it doesn't work well when transferring large graphs.
So far I remember (but maybe things changed in the meantime), when you transfer an lazy loaded entity, the parts that haven't been loaded yet are sent as-is (the proxy is serialized), which means you can not access them on the client because lazy loading won't work if there is no session anymore. Are you eagerly loading the entity before sending it back to the client?
But the crux of the problem is that you are in a scenario where you need to think about a strategy to transfer data. You must design you application is a way that you don't send large graphs; this concern must be addressed in the design of your app. Then you can decide to still send JPA entities or rely on Data Transfer Object (DTO).
You might also consider using an extended persistence context with a stateful session bean, this way I think an entity on the client side can still be loaded lazy. But I never used this personally and don't know if it works well or not.
如果我正确理解你的架构，你会发现：
实际上，你的 SLSB 正在用 JPA 对象表达它们的接口，你的 DTO 就是 JPA 对象。我看到两种可能的情况：
我的感觉是，您应该首先确定您在客户端中获得的内容。添加一些跟踪语句来准确查看您拥有的数据应该很容易。
可能通过调整延迟加载等，您可以控制行为。
我的期望是，您可能需要定义特定于客户端的“子集”DTO，并让 SLSB 更多地充当外观，仅发送子集数据。这需要更多工作，但您可以很好地控制界面中的内容。
从架构上来说，微调远程接口是一件相当合理的事情。
If I understand your architecture correctly you have:
In effect your SLSBs are expressing their interface in terms of the JPA Objects, your DTOs are the JPA objects. I see two possible scenarios:
My feeling is that you should first determine exactly what you are getting in the client. Should be pretty easy to add some trace statements to see exactly what data you have.
Possibly by tweaking the lazy loading etc, you can then control the behaviour.
My expectation is that you may need to define client-specific "subset" DTOs and have your SLSB act more as a facade, sending only the subset data. It's more work, but you have fine control over what's in the interface.
Architecturally, fine tuning a remote interface is quite a reasonable thing to need to do.
你无法加速事情的发展。但是，您可以传输较少的内容（仅传输所需的部分或较轻的物体）。
You can't accelerate things. However, you can transfer less (only the required part or lighter objects).