对于过度的互联网交易，JPA + EJB的速度是否很慢（或很重）？

Question

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

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

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

我可以采取措施加快JPA / EJB服务器与远程Java客户端之间的事务处理速度吗？

提前谢谢。

Answer 1

您真的转移了多少数据？也许你发送的采购订单有一个产品，有一个模型，有一个供应商，有一套模型......等等......

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

Answer 2

  

我正在查看流量图以及何时   我在客户端合并了一个实体   应用程序我看到兆字节的流量   （我简直不敢相信如何购买   订单实体的重量可能超过1   MB）。

RMI-IIOP比普通RMI更冗长。根据我的经验，它在传输大图时效果不佳。

到目前为止，我记得（但也许事情发生了变化），当你转移一个延迟加载的实体时，尚未加载的部分按原样发送（代理被序列化），这意味着你可以不能在客户端上访问它们，因为如果没有会话，延迟加载将不起作用。在将实体发送回客户端之前，您是否急切地加载实体？

  

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

但问题的关键在于，您需要考虑转移数据的策略。您必须设计应用程序是一种不发送大图形的方法;必须在应用程序的设计中解决这个问题。然后您可以决定仍然发送JPA实体或依赖数据传输对象（DTO）。

您可能还考虑将扩展持久化上下文与有状态会话bean一起使用，这样我认为客户端上的实体仍然可以加载延迟。但是我从来没有亲自使用它，也不知道它是否运作良好。

Answer 3

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

 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更多地作为外观，仅发送子集数据。这是更多的工作，但你可以很好地控制界面中的内容。

在架构上，微调远程接口是非常合理的事情。

Answer 4

  

我可以采取措施加快JPA / EJB服务器与远程Java客户端之间的事务处理速度吗？

你无法加速。但是，您可以减少传输（仅限所需的部分或较轻的对象）。