Java Persistence API (JPA)是存取Java关系数据的企业级标准。JPA为Java对象映射到数据库图解提 供支持，包括一个简单的API设计和查询语言的表达，查询语言的表达是为了检索来自数据库映射的结果 ，并且因为这个结果改变回执 。JPA通过书写以及维护他们自己的映射代码、允许存在单一的API而不管 平台、应用服务器或者提供持久执行为开发者提高生产率。这些高速缓存解决方案允许经常的存取实体到 存储器，可以减少到数据库查询的次数和大量花费在转换数据库查询结果到对象上的处理时间。高速缓存 可以深入的积极的对应用性能产生影响。
JPA和数据网格
数据网格是运行在有代表性的低耗硬件群集上面的软件，支持数据存贮和处理服务。数据网格产品聚 集了处理能源和存储群集服务的能力，使得客户端通过API可以使用它，API是为防护设计的，避免分布式 计算的复杂。数据网格作为可伸缩的分布式存储被普遍运用;无论如何，分布式数据处理也是常见的特性 。作为存储器，数据网格提供一种方法来超越单一服务器因为堆栈大小的限制，这个解决办法就是通过分 布式数据存取所有的集群服务器。
尽管他们在专业技术领域内的应用被限制。但是在当今企业应用中，与数据网格相关的话题仍然层出 不穷。数据网格已经成为一种主流，当开发应用程序的时候，开发者需要考虑网格架构，并且意识到在未 来，网格在应用程序中的应用比例会被提高。
考虑一个银行系统，通过在写入数据库前确认所有项目来处理存款和撤销请求。确认的内容也许包括 帐目是否有效、提出请求的是否是户主、账户上是否有户主要求提取的存款数额等等。你可以想象，在这 样一个系统中还有很多需要确认的地方。你需要从数据库中读取数据总和，数据总和执行一个确认的单一 请求是有重要意义的，并且会引起很多查询。幸运的是，在JPA中创建这样一个以数据库为中心的应用程 序是非常简单的。绘制领域内的每一个classe到数据库，并且书写必要的JP QL查询来检索确认的对象。 系统也许不得不从数据库读取大量的数据来处理每一个请求，但是它运作的很好。
现在，如果我们需要显著的提高这个系统的生产力，我们不得不解决它唯一但是最大的瓶颈：通过查 询数据库得出确认数据。大多数JPA执行不是提供一个L2存储功能，就是支持第三方L2存储功能的整合。 但是，如果我们不得不处理大量随机到达的请求，在存储器中拥有必须的参考数据是不太可能的事情。存 储器在你重复的存取一些数据是非常的有效。如果你存取的是随机数据，存储器不太可能储存你当即所需 要的数据。当然，你可以不停的增加存储器的容量来满足你的需求，但是每一个服务器只能拥有这么多的 堆栈。
数据网格提供一种方法来超越单一服务器因为堆栈大小而产生的限制以及在集群服务器上分布存储对 象。现在要面临的挑战是将数据网格技术与JPA融合，从而能够提高生产力，而不需要完全改写应用程序 。当然，作为软件系统的代表性案例，有很多案例是接近一体化的，每一个都伴有各自的优势劣势。让我 们来看看整合的体系架构以及我们应该如何使用。
数据网格作为中间级别的对象存储
像我们前面所提到的，数据网格产品可以扩展存储，存取一个集群，并且可以作为一个共享的中间存 储使用。他们提供一个单一的逻辑堆栈，可以从物理层面进行扩展，这种扩展是伴随着全部的存储容量在 多重服务器上实现的，全部的存储容量是包括所有的群集服务器的堆栈。在例子当中，这意味着通过增加 更多的服务器到网格，它的存储容量可以增加，要点是所有的确认数据必须预先加载(通常是“加热”存 储器)。自从确认数据的存取成为我们的瓶颈，存取所有的必须数据在实际上消除了这个问题。
举例来说，在我们的银行系统中，考虑一个简单的可以确定的方法：
public boolean isValidAccount(Request request) { Account account = entityManager.find( Account.class, request.getAccountId()); if (account == null) { return false; } else { return account.isValid(); } }
伴随着数据网格整合成为L2存储器，查询功能将会检查网格所需要的账户。如果不查询，它可以转而 查询基础数据库。无论如何，如果网格中包含了所有的帐号信息，这就没必要查询数据库，预热应用存储 器可以从确认队列中完整的清除数据库存取过程。
主键查询可以很容易的运用到数据网格中，但是JP QL查询如何那?考虑这种方法，使用非主键查询的 请求：
public Customer getTxCustomer(Request request) throws NoResultException { Customer customer = entityManager .createQuery("select c from Customer c where c.masterAccountId = :id") .setParameter("id", request.getMasterAccountId()) .getSingleResult(); return customer; }
查询数据网格，得出一个匹配随意准则的对象仍然是一件困难的事情。首先，它依赖于数据网格是否 提供某种查询框架，第二，JPA/data网格一体化可以将JP QL转化为此框架。如果满足这两个必要条件， 我们例子中的查询就可以被应用在网格中，而不是数据库中。
这种方式的另一个很有价值的特性是执行并行查询的可能性。显而易见的是我们例子中的查询可以在 网格中所有的服务器上并行执行，查找需要的对象。无论如何，一个查询执行后返回很多的对象是件有趣 的事情。每一个网格服务器都可以执行并行查询来识别这些对象，使其与被给予的标准相匹配。在10000 个对象上并行执行这种查询十次比在100,000个对象上查询一次的速度快得多。服务器越多，每个服务器 上分配的对象数量就越少，查询速度也就越快!
遗憾的是关于查询问题还是有一个麻烦，就是返回多重结果。与主键查询不同，主键查询中如果存储 器失误会自动的引起数据库查询，而现在，是否从网格中得到足够的结果是不明确的。也许你只能查询网 格中的一部分对象，所以一个网格查询是无法返回数据库中其他部分的查询结果。通过确保所有的对象都 在网格中，预热存储器解决了这个问题， 但这并不总是可行。无论如何，对于一个特定的使用案例，也 许你知道一个特有的查询是否需要网格或者数据库。再JPA中通过查询节点实现查询功能的。也许就像下 面的演示：
Customer customer = entityManager .createQuery("select c from Customer c where c.masterAccountId = :id") .setParameter("id", request.getMasterAccountId()) .setHint("my-jpa-implementation.dont-query-grid", true) .getSingleResult();
当然，现在没有JPA标准来说明是否把查询用于数据网格。这意味着你不得不在你编译的代码中采用特 殊执行的节点。幸运的是，JPA规范依赖于执行，忽略那些不明白的的节点，所以你编译的代码并没有因 为节点而与任何一个特定对象结合。
更新对象
当你看到网格上面的JPA，很自然的你会首先想到查询，但是我们也不得不考虑更新：输入新对象，修 改现有对象，以及删除对象。当网格在L2存储器中时，确定网格的更新仅仅在数据库执行过程成功交付之 后产生是非常重要的。输入新对象会引起数据库INSERT并且新对象会被放置到网格中。修改对象会引起数 据库UPDATE，并且被更新的对象会被放置到网格中。最后，删除一个对象会引起数据库DELETE，并且这个 对象会从网格中被移除。关键点是更新数据网格一次，数据库执行过程可以成功交付。
数据网格作为系统备份
当JPA使用数据网格作为一个分布式存储器，数据库就成为了“系统备份”。这是系统本来面目的最终 来源，并且保持实时更新。但是数据网格实现备份的意义是什么?这个案例经常使用在金融应用软件上， 用以处理快速的变化以及过度过程数据。如果没有数据库，或者数据库仅仅被用来存放数据，或者是只是 一个货舱而不是联机系统，网格上面的JPA看起来会怎么样?
时间慢慢的流淌，人生有风雨阳光，
