在这个架构中，所有的JPA操作用于替代数据网格，JPA操作通常会使用SQL用于数据库。这包括所有的查询和所有的更新。根本上，我们用数据网格完全的取代数据库。伴随着JP QL转换支持，尽管数据存储是专门在中间层操作，我们仍然可以继续使用JPA为我们设计API。对于系统而言，不需要长期持久的存储，这是理想状态。如果要求更多的存贮或者查询性能，你可以简单的增加服务器到网格。
数据库——依靠数据网格
即使所有的查询和更新执行都朝着不利于数据网格的方向发展，它仍然有可能融入到一个持久存储器数据库。在这个构架当中，网格负责传递网格中的操作性能到数据库。比如说，输入一个对象到网格将会引起数据库的INSERT操作。这个架构的优势是数据仍然可以频繁使用，而更新会返回到数据库，并且可以报告目的等等。理想的情况下，网格操作不会同步传递到数据库，这样的话会明显地减弱生产力。异步书写更新到数据库可以保持网格的灵敏性，并且支持持久性存储的要求。
混合以及匹配——多种结构
迄今为止，我们把数据网格作为JPA的存储器对待，并且认为JPA是数据网格上层的API标准。这个架构之间的不同点实在不明显。对于新对象来说，归结到配置上面，要看JPA是否是首先书写在数据库上，然后写入数据网格，或者是否它仅仅是写在网格上面。处理更新以及删除操作时候的逻辑与上面相同。就像我们看到的，查询操作也与此类似。如果我们可以设置如何在一个实体对实体的基础上读取、输入、查询，我们就可以混合这些架构。考虑存储器与应用程序之间的往来。在这样一个应用程序中，你可以得到“持久的”实体。但是你也会得到短暂的实体。为了一个持久的实体，实体级别的架构可以使得JPA使用数据网格作为存储器。
按照数据网格修改JPA
如果顺利的话，把JPA与数据网格相结合是很有可能的，并且可以通过提供快速存取来提升系统的生产力，从而在中间层进行数据管理。但是他们也为JPA应用程序提供测量标准，与普通方法相比它的可测量性更显著。
传统意义上，提高JPA应用程序的应用率需要提高应用群集上服务器的数量，使用下载平衡来均匀的分布工作。但是当你提高群集的大小，发现这个群集大小是受你限制的，限制它可以存储的内容而不需要引进进程之间的通道和连接。更新然后共享数据可以传递到所有的群集服务器，来确定JPA存储器不包含陈旧的数据。对于一个伴随着N个服务器的群集来说这意味着每一个更新将会产生N-1个信息。当你增加群集中服务器的数量，每一个服务器处理一个单一的同步更新的花费依据(N-1)²这样的速率增加，因为任何一个更新发生，每一个服务器都必须与其它所有的服务器通信。更糟糕的是，伴随着群集的增长，每一个服务器都不得不花费大量的可用处理时间来解决新到达的更新信息。那些非线性的通信以及更新处理成本意味着群集JPA应用程序的传统方法利用存储器可以很好的工作，他们受限于小到中型号的群集。
通过拥有一个可共享副本，数据网格能够解决通信上的问题，这个副本来自所有服务器的易存取的对象。一个更新操作是不需要依赖于将信息传递到所有服务器的，因为在下次他们需要更新对象的时候，是可以跟上变化的。在一个数据网格中，伴随着可升级的点对点通信架构(即不需要中心信息就可以打破瓶颈)，一个更新是依赖于到服务器的通信的，这是个存储对象的服务器，或者是一个存储备份的服务器。这种情况下，存取每个服务器单一的同步更新上的通信花费是可以用线性函数C(N)描述的，C是副本(基本的以及备份的)数量的持续反映。这种线性更新的花费意味着通过使用数据网格来扩展群集有可能实现评测JPA应用程序，以及达到更高的生产力。
质疑
当然，网格上的JPA从来都不缺乏挑战。第一条就是开发者对于对象关系映射非常的熟悉，JPA无疑会被认为缓存疲劳。这是存储器带来的最常见的问题。缓存疲劳有两个原因：第三方更新数据库，以及JPA应用程序运行在其他服务器群集上实现更新操作。处理第三方更新问题与处理处理数据网格没有什么不同，大多数JPA执行提供一系列的技术来处理这些问题，包括驱逐规则，查询恢复原则，以及针对极易变更的数据，废除存储的能力。这已经是一个陈旧的话题，数据网格不会特别的复杂化。
就像之前讨论的那样，缓存疲劳影响更新，使得在其他群集服务器中使用传统的解决方法，也就是通过信息解决，尽管它有自己的限制。再高处理速率的系统中，信息顶层是非常重要的，JPA应用程序趋向于把缓存的使用降至最低，依赖数据库来确定他们是不是将数据更新。具有讽刺意义的是，处理速率提高以及存储器价值的提高经常是有缺陷的，因为维护存储器持续运作的花费实在是太高了。实际运用数据网格来删除信息以及更新处理情况意味着高速处理系统可以利于存储器达到甚至是超越生产力，而不需要管理缓存疲劳。
查询是另一个挑战。JPA界定了JP QL的多种用途，在很多方面与SQL是相似的，包括很多相同的小细节。JP QL的目标是提供一个以对象为基础的查询语言，可以简单的转换为执行在关系数据库上的SQL。当然，数据网格不是关系数据库，每一个数据网格拥有自己的查询框架。JP QL可以被转化的范围以及在特定网格上面的执行都要依靠网格查询框架的性能。
另一个挑战来自关系对象。JPA支持很多的关系类型，除了嵌入式对象。通过数据网格产品，关系对象的支持呈现各种不同的形式，每一个都有细微的差别。焦点包括：哪一种类型的关系对象可以支持;对象之间是否可以通过网格关联或者更多的是驻扎在一点;在关系对象中哪一种查询操作是被支持的。最后一个问题的答案明显对于哪一种JP QL查询可以执行有重大影响。
这个列表很明显是不全面的，但是它提炼了对PA/data网格整合有影响的问题中的精华部分。
结论
数据网格不是关系数据库，所以我们不能期望JPA与数据网格之间有一个完美的契合。但是，即便有很多限制，网格上面的JPA也是令人激动的技术，它提供了一种方法：进化JPA应用程序使其站在杠杆的另一端，撬动数据网格能够创建可升级的高速率系统。