IBM WebSphere Application Server V7 交付了对其 Java Persistence API (JPA) 实现的增强，支持对 IBM DB2 数据服务器数据访问的优化，以提高安全性，并具备显著降低 数据访问开销的潜力。实现优化的方式是通过使用 WebSphere JPA 与 IBM Data Studio pureQuery 运行 时之间的内置集成来支持静态 SQL 访问——这一切全都不需要更改应用程序代码或运行广泛 的测试用例。
引言
IBM WebSphere Application Server V7 交付了增强的 Java Persistence API (JPA) 实现，可支持 pureQuery，从而可以支持用于 DB2 的静态 SQL。本文介绍如何利用通过 IBM Data Studio pureQuery 运行时提供的静态 SQL 的性能和安全性，同时使用 JPA 实现其完整的对象关系功能。它几乎就像拿起您 的蛋糕并将其吃掉一样简单。
在简要介绍一些有关 SQL 和 pureQuery 的信息之后，本文将对动 态 (JDBC) 访问与通过 JPA 的静态 (pureQuery) 访问进行更详细的比较和对比。您将了解如何使用 WebSphere Application Server V7 中的静态生成器 (wsdb2gen) 实用工具来生成 SQL，然后了解如何将 生成的 SQL 绑定到 DB2 包中。本文在结束时简要概述了如何使用 pureQuery 客户端优化功能作为对这 里描述的静态生成器功能的补充。
先决条件
本文假设读者基本熟悉 JPA。
基础
什么是静态 SQL？
DB2 中的静态 SQL 是一个强大的功能，可以通过预先执行某些工作来简化运行时的数据访问，例如确 定数据库访问路径。这可以使运行时执行得更快速并且更加一致。
图 1. 静态执行比动态执行更 加高效
静态 SQL 的安全模型也不同于动态 SQL 的安全模型。使用静态 SQL，用户仅收到执行绑定进程输出 （称为包）的权限，并且该包包含 SQL 语句。换句话说，如果对某个表的所有访问都是静态的，则 DBA 将不需要授予对整个表或视图的访问权限，而是仅授予对包的访问权限。此外，可静态执行的 SQL 越多 ，则意味着恶意注入 的机会越少，恶意注入是动态 SQL 的一个众所周知的安全问题。