在这个架构中，所有的JPA操作用于替代数据网格，JPA操作通常会使用SQL用于数据库。这包括所有的 查询和所有的更新。根本上，我们用数据网格完全的取代数据库。伴随着JP QL转换支持，尽管数据存储 是专门在中间层操作，我们仍然可以继续使用JPA为我们设计API。对于系统而言，不需要长期持久的存储 ，这是理想状态。如果要求更多的存贮或者查询性能，你可以简单的增加服务器到网格。
数据库——依靠数据网格
即使所有的查询和更新执行都朝着不利于数据网格的方向发展，它仍然有可能融入到一个持久存储器 数据库。在这个构架当中，网格负责传递网格中的操作性能到数据库。比如说，输入一个对象到网格将会 引起数据库的INSERT操作。这个架构的优势是数据仍然可以频繁使用，而更新会返回到数据库，并且可以 报告目的等等。理想的情况下，网格操作不会同步传递到数据库，这样的话会明显地减弱生产力。异步书 写更新到数据库可以保持网格的灵敏性，并且支持持久性存储的要求。
混合以及匹配——多种结构
迄今为止，我们把数据网格作为JPA的存储器对待，并且认为JPA是数据网格上层的API标准。这个架构 之间的不同点实在不明显。对于新对象来说，归结到配置上面，要看JPA是否是首先书写在数据库上，然 后写入数据网格，或者是否它仅仅是写在网格上面。处理更新以及删除操作时候的逻辑与上面相同。就像 我们看到的，查询操作也与此类似。如果我们可以设置如何在一个实体对实体的基础上读取、输入、查询 ，我们就可以混合这些架构。考虑存储器与应用程序之间的往来。在这样一个应用程序中，你可以得到“ 持久的”实体。但是你也会得到短暂的实体。为了一个持久的实体，实体级别的架构可以使得JPA使用数 据网格作为存储器。
按照数据网格修改JPA
如果顺利的话，把JPA与数据网格相结合是很有可能的，并且可以通过提供快速存取来提升系统的生产 力，从而在中间层进行数据管理。但是他们也为JPA应用程序提供测量标准，与普通方法相比它的可测量 性更显著。
传统意义上，提高JPA应用程序的应用率需要提高应用群集上服务器的数量，使用下载平衡来均匀的分 布工作。但是当你提高群集的大小，发现这个群集大小是受你限制的，限制它可以存储的内容而不需要引 进进程之间的通道和连接。更新然后共享数据可以传递到所有的群集服务器，来确定JPA存储器不包含陈 旧的数据。对于一个伴随着N个服务器的群集来说这意味着每一个更新将会产生N-1个信息。当你增加群集 中服务器的数量，每一个服务器处理一个单一的同步更新的花费依据(N-1)2这样的速率增加，因为任何一 个更新发生，每一个服务器都必须与其它所有的服务器通信。更糟糕的是，伴随着群集的增长，每一个服 务器都不得不花费大量的可用处理时间来解决新到达的更新信息。那些非线性的通信以及更新处理成本意 味着群集JPA应用程序的传统方法利用存储器可以很好的工作，他们受限于小到中型号的群集。
通过拥有一个可共享副本，数据网格能够解决通信上的问题，这个副本来自所有服务器的易存取的对 象。一个更新操作是不需要依赖于将信息传递到所有服务器的，因为在下次他们需要更新对象的时候，是 可以跟上变化的。在一个数据网格中，伴随着可升级的点对点通信架构(即不需要中心信息就可以打破瓶 颈)，一个更新是依赖于到服务器的通信的，这是个存储对象的服务器，或者是一个存储备份的服务器。 这种情况下，存取每个服务器单一的同步更新上的通信花费是可以用线性函数C(N)描述的，C是副本(基本 的以及备份的)数量的持续反映。这种线性更新的花费意味着通过使用数据网格来扩展群集有可能实现评 测JPA应用程序，以及达到更高的生产力。