Java在网格方面的持久应用：整合途径 （一）(2)

举例来说，在我们的银行系统中，考虑一个简单的可以确定的方法：

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个对象上查询一次的速度快得多。服务器越多，每个服务器 上分配的对象数量就越少，查询速度也就越快!

Java在网格方面的持久应用：整合途径 （一）(3)

遗憾的是关于查询问题还是有一个麻烦，就是返回多重结果。与主键查询不同，主键查询中如果存储 器失误会自动的引起数据库查询，而现在，是否从网格中得到足够的结果是不明确的。也许你只能查询网 格中的一部分对象，所以一个网格查询是无法返回数据库中其他部分的查询结果。通过确保所有的对象都 在网格中，预热存储器解决了这个问题， 但这并不总是可行。无论如何，对于一个特定的使用案例，也 许你知道一个特有的查询是否需要网格或者数据库。再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存储器中时，确定网格的更新仅仅在数据库执行过程成功交付之 后产生是非常重要的。输入新对象会引起

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!