4

我正在开发一个独立的 Java 客户端应用程序，它连接到 Glassfish v3 应用程序以进行 JPA/EJB 外观样式事务。换句话说，我的客户端应用程序不直接连接到数据库到 CRUD，但它使用 EJB 无状态会话传输 JPA 对象。

我有这样的场景，这个客户端应用程序将用于通过 Internet 连接 VPN 的外部网络，客户端连接为 512kbp/DSL，一个简单的查询需要很长时间，我看到了流量图，当我合并一个客户端应用程序中的实体我看到了兆字节的流量（我无法相信采购订单实体的重量如何超过 1 mb）。

我在几乎每一个多对多关系中都有 LAZY 获取，但我在实体之间有很多多对一关系（但这是 JPA 的巨大优势！）。

我可以做些什么来加快 JPA/EJB 服务器和远程 java 客户端之间的事务速度吗？

先感谢您。

4

4 回答 4

1

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).

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?

Could I do something to accelerate the the speed of transactions between JPA/EJB server and the remote java 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.

于 2010-04-21T07:39:29.400 回答
1

您真正传输了多少数据？也许您发送的采购订单有一个产品，它有一个模型，它有一个供应商，它有一组模型......等等......

您可以尝试将要发送到服务器的对象序列化为文件（使用标准 ObjectOutputStrem）并检查文件的大小。

于 2010-04-21T06:24:21.210 回答
0

如果我正确理解您的架构，您将拥有：

 Client(works with disconnected Entities)  
            ----RMI/IIOP--->
 Server(SLSB, using entitiy manager, JPA persistence) 
            ----JDBC------->
 Database

实际上，您的 SLSB 是根据 JPA 对象表达它们的接口，您的 DTO 是 JPA 对象。我看到两种可能的情况：

  1. 您的客户只需要 JPA 对象中的数据子集，而您传输的数据超出了实际需要。例如，您可能只需要一个员工的姓名，然后发送他的整个人生经历。
  2. 您正在遍历的关系树比您预期的要多

我的感觉是，您应该首先确定您从客户那里得到了什么。添加一些跟踪语句以准确查看您拥有的数据应该很容易。

可能通过调整延迟加载等，您可以控制行为。

我的期望是您可能需要定义特定于客户端的“子集”DTO，并让您的 SLSB 更像是一个门面，只发送子集数据。这是更多的工作，但您可以很好地控制界面中的内容。

从架构上讲，微调远程接口是一件非常合理的事情。

于 2010-04-21T10:11:12.317 回答
0

我可以做些什么来加快 JPA/EJB 服务器和远程 java 客户端之间的事务速度吗？

你不能加速事情。但是，您可以传输更少（仅需要的部分或更轻的物体）。

于 2010-04-21T21:17:56.090 回答