JPA相关知识

这篇文章是摘自Patrick Linskey的一篇文章，主要是关于JPA相关内容的问答，相信JPA面试会碰到不少这里面的问题

问题：EJB专家团队是如何摆脱事务描述符的?

回答：在会话bean和消息驱动bean中，能够经过描述符和注释来控制事务的行为。此外，咱们将默认的事务属性更改成“REQUIRED”，这个默认值比之前的值“SUPPORTS”更经常使用。所以，彻底没必要为业务方法配置事务行为。

JPA实体仅供本地使用，重点关注域模型。所以，没法在JPA实体上配置事务性(或远程边界或安全性)。而是必须使用会话bean façade(或消息驱动bean)，才能够经过EJB协议使用这些实体。一般来讲，这是一件好事，配置安全性、远程处理和事务的粒度应该比持久化数据的粒度粗不少。JPA着重关注持久化数据，以及与EJB的其余部分和Java EE规范集成起来照管其余企业关注点。

问题：推荐对主键使用“long”仍是“Long”?若是容许使用null做为值，将会如何?

回答：这实际上取决于您的数据模型。若是您的数据模型容许主键为null，那么使用Long，若是您的数据模型规定主键列不能为null，则使用 long更合适。总的来讲，我认为对于非复合主键，容许null做为合法值容易产生混淆，所以我倾向于使用long，而不是Long。

问题：您说EJB 2.0不支持继承，可是能够在几个不一样位置(远程/bean)使用继承，只是不在本地使用而已。请解释一下。

回答：根据EJB 2.1规范的附录D3：

当前的EJB规范未指定组件继承的概念。

另外一方面，JPA规范确实规定了实体继承的概念。咱们已经处理了EJB 2.1规范中指出的各类问题和复杂性，如今容许彻底的多态查询和关联。

问题：BEA计划何时支持/发布EJB3?

WebLogic Server 10 Technology Preview 是彻底符合规范的Java EE 5应用服务器。它包括完整的EJB3支持。WebLogic Server 10大概于三月下旬发布。

此外，Kodo 是彻底符合规范的生产就绪JPA实现，而且已经发布。

问题：JPA是否支持组合主键?

回答：JPA支持天然ID和组合ID，以及数据库指派或实现指派的数字值。

问题：是否存在Spring模板，像JDBC模板同样能够在容器外部使用?

回答：是的，Spring 2有JPA模板。可是，Spring 2能够对任何标记着@Repository的bean执行JPA异常转译。所以，总的来讲，对于新的应用程序，最好直接使用JPA API，而不是另外一个模板层。对于使用模板和正在迁移到JPA的现有应用程序来讲，使用模板方法比较合理。

此外，能够像在Java EE服务器中同样将JPA的持久化单元部署到Spring，Spring对JPA规范中指出的EntityManager注入和查找服从容器规则。

问题：JPA是否支持JDK1.4?

回答：JPA须要Java 5或更新版本。

问题：使用范围查询时，它是否也会返回结果总数(例如，返回538项结果中的1-10项)?

回答：不，要想得到总数，必须发出另一个查询。通用模式是，在第一次执行搜索时得到总数，而后经过页面浏览结果，将总数存储到方便的位置(会话状态、cookie等)：

if (isFirstPage()) { // this is the first time we’re executing this query
Query q = em.createQuery(“SELECT COUNT(p) FROM Product p WHERE …”);
long count = ((Long) q.getSingleResult()).longValue();
// store count somewhere stateful
}
Query q = em.createQuery(“SELECT p FROM Product p WHERE …”);
q.setFirstResult(page * PAGE_SIZE); // page is stored somewhere stateful
q.setMaxResults(PAGE_SIZE);

问题：具备JPA包装器的Hibernate是否是一种EJB3实现?

回答：JPA规范是完整的EJB3规范的子集，所以JPA实现自己不是完整的EJB3实现。我不了解RedHat的EJB3实现的状况如何。但，Hibernate是JPA实现。

问题：与Hibernate相比，JPA是否是更好?

回答：JPA是规范，而Hibernate是实现。所以，这是不一样事物的比较。能够确定，使用标准API比使用专有API有更多优点，但不存在真正的劣势。

问题：是否是再也不须要学习和使用Hibernate?

回答：规范团队关于JPA 1的目标之一是制定一个能够由不少供应商实现的API，而且开发人员能够编码来实现该API，而不是使用私有供应商特有的API。咱们已成功实现这个目标，所以您只需使用供应商特有的API来得到JPA规范没有解决但您的应用程序中须要的功能。个人建议是尽量地使用JPA API，可是当须要供应商公开可是规范中没有提供的功能时，则使用供应商特有的API。

例如，OpenJPA提供了保存点功能，但JPA规范没有。所以，但愿使用保存点的OpenJPA开发人员应该对代码的大部份内容使用JPA规范，而借助OpenJPAEntityManager来设置和管理保存点。

问题：规范是否解决了缓存问题?

回答：JPA规范没有解决二级缓存问题(EntityManagerFactory-级)，可是提供了实现该缓存必须遵照的一些数据锁定和一致性规则，即便在启用缓存时也是如此。

有少许与缓存有关的主题可能会在未来的JPA规范版本中解决，可是大多数缓存主题没必要指定规则，这样，不一样的供应商就能够轻松地完成不一样的工做。此处增长的最重要的内容是一些基本缓存控制API，如回收某些对象ID，或将一些常常访问的ID固定到缓存中。

问题：既然实体管理器承担了全部繁重的工做负载，那么会话bean还有什么价值?

回答：EntityManager负责域对象模型和数据库之间的交互，可是仍然在会话中实现安全性、事务控制、远程处理、有状态的临时数据存储，而操做单元编程模型没法解决以上问题。会话bean仍是部署单元和公用服务边界。所以，会话bean是定义全部业务代码的地方。换而言之，会话bean是EJB 容器关注的，而JPA实现是在会话bean中使用的。

固然，您还能够直接从servlet或JSP或其余任何可使用Java 5的地方使用JPA。可是这样的话，您就必须管理本身的事务、处理本身的集群服务故障转移、管理本身的服务重部署等。

问题：相对于EJB2来讲，EJB3能够处理多少个并发事务?

回答：从纯会话bean的观点来说，至少在WebLogic Server中，并发事务的数目没有什么差异。也就是，若是将您的应用程序从EJB2会话bean转换到EJB3会话bean，可是彻底没有修改持久化机制，可能不会发现重大差异。这是由于EJB3规范对会话bean部分的大多数更改着重实现编程模型的改进。

从实体bean的观点来说，我认为对于大多数应用程序，WebLogic Server的EJB 2.1和JPA支持的并发事务数目相同。您可能发现JPA对于非主键的查询来讲，可伸缩性更高。一旦开始钻研Kodo的 锁定组之类的功能，则对于固定的域模型，能够从基于JPA的系统中得到更多并发事务。

问题：如何为AquaLogic DSP应用JPA?

回答：AquaLogic DSP着重关注对数据的多重存储访问，并将数据做为数据服务提供，一般做为XML或SDO呈现这些数据。JPA规范着重关注与数据存储交互的Java API。能够设想，JPA绑定到AquaLogic DSP，或SDO绑定到Kodo产品(BEA的JPA实现)。

问题：什么是实现过程的最佳位置，例如，检查许多用户及其账户(在银行应用程序中)以付给利息?是在数据库的存储过程当中实现，仍是在EJB中使用JPA实现，仍是同时使用这两种方式?

回答：根据个人经验，这实际上取决于组织因素，而不是其余因素。一些工做室更喜欢在存储过程当中进行大量编码，而另外一些则喜欢在Java中实现其业务逻辑。每种方法各有优点和代价。

尽管如此，仍是有一些问题可促使他们优先考虑其中的一种环境。在您的例子中，在数据库中执行大量计算可能比将数据加载到内存中更快，所以使用存储过程可能比较合理。另外一方面，数据库承担这么多负载将对该应用程序的用户产生负面影响，所以最好付出必定代价跨网络拉出这些数据，以便将该数据库用做严格的存储系统，而不是计算引擎。或者，若是应用程序的其他部分主要使用JPA，则适用的话，可能但愿使用JPQL的大批量更新功能来进行更新。

问题：若是不先将数据加载到内存中，是否能够执行大批量更新?

回答：是的，能够经过JPQL执行大批量更新和大批量删除：

UPDATE Employee e SET e.salary = e.salary * 1.1 WHERE e.salary < 100000

问题：大家对Kodo JDO有什么规划?JPA是否会经过实现JDO的全部功能而将其取代?若是是的话，是否存在任什么时候间表?若是不是，大家会不会继续积极地开发JDO?

回答：BEA仍然彻底忠于JDO。从规范的观点来看，我认为过一段时间以后，JPA将包含当前的JDO规范中愈来愈多的功能。可是，我不了解Sun对JDO和JPA之间的融合工做有什么规划。

问题：什么是持久化单元?

回答：持久化单元是类和配置设置的集合，能够根据该集合建立EntityManagerFactory。它在 persistence.xml 文件中做为一个条目出现。

问题：如何在WebLogic 9.2中测试JPA

回答：如今能够在WebLogic 9.2中使用OpenJPA或Kodo。该服务器不执行会话bean持久化单元注入，可是在10.0服务器中能够这么做，而且在9.2中，没有任何 Kodo控制台集成。可是除了引导注入问题以外，应该可以在WebLogic 9.2中成功地使用JPA，包括参与托管事务。

问题：JDBC链接对应于JPA中的什么概念?

回答：JPA EntityManager大体至关于JDBC链接，而JPA EntityManagerFactory从概念上相似于JDBC数据源。JPA EntityTransaction(仅在JTA / appserver上下文之外可用)至关于JDBC链接的事务控制API。

在OpenJPA中，EntityManager在其生命周期中可能使用多个不一样的JDBC链接。请参阅 openjpa.ConnectionRetainMode 属性的文档了解详细信息。

问题：关于fetch类型，若是默认是主动(eager)加载，则提供程序可能忽略惰性(lazy)加载指令。所以，即便将字段设置为惰性，也可能会加载没必要要的数据。未来的规范会不会将其修改成必须与fecth类型一致?这会涉及到什么问题?

回答：一般，OpenJPA永远不会忽略用户配置的FetchMode。这是提示而不是规则，由于惰性加载其实是调优过程当中一项关注事项，永远都不该该对应用程序产生行为性的影响*。JPA规范力图避免要求使用任何明确的性能调优策略，由于不一样的网络拓扑结构、数据存储系统和应用程序行为须要不一样的调优关注。

例如，OpenJPA容许在运行时 动态控制 fetch配置。这意味着，它可能静态地配置对象模型，使某些字段进行惰性加载，而后动态地将其中一个字段添加到当前的fetch计划。这将致使OpenJPA违反静态定义的惰性设置。

在当天结束时，若是实现对数据加载执行错误的操做，您应可以很是轻松地评估其余实现，经过威胁转移到另外一个实现，以致少得到所需的功能。这是让大量供应商采用JPA规范的重大优点之一。

*固然，若是您依靠惰性加载设置来防止加载某些数据，以避免后来传输到不一样的层(也就是为了数据安全性)，那么惰性加载存在重要的行为性影响。在OpenJPA中，可使用 fetch组 控制经过电缆发送数据图时确切地分离哪些数据。

问题：在运行时更改fetch模式容不容易?

回答：JPA规范没有为此提供任何工具。OpenJPA经过 fetch规划 接口提供了对fetch特征的详细控制。JPQL的“JOIN FETCH”结构也能够用于限制主动fetch提示。

问题：使用乐观锁定时，@Version注释仅支持int字段吗，它能够是datetime吗?

回答：根据JPA的要求，@Version能够对int、long、short、Integer、Short、Long和Timestamp类型的字段使用。(JPA规范的第9.1.17小节)。

问题：在JPA能够调用存储过程吗?

回答：JPA规范仅要求支持SELECT SQL语句(经过EntityManager.createNativeQuery()调用，或@NamedNativeQuery注解或named- native-query XML元素)。可是，我认为大多数实现也多少支持以相同方式调用存储过程。

问题：在EJB3中，更新实体bean的单个字段/列会致使更新该DB行中的全部字段/列，仍是仅更新该DB行中更改的列?

回答：该行为取决于实现。OpenJPA将只更新被修改字段对应的列。可是，咱们可能在某些位置添加update-all-columns选项。请参阅 OPENJPA-38。

问题：EJB3.0如何替换EJB2.0中的ejbLoad()、ejbStore()之类的回调方法?

回答：JPA规范提供了一些能够随意(单个)实现的 回调方法。

问题：EJB3.0如何替换EJB2.0 CMP和BMP?

回答：EJB3 JPA规范对EJB2 CMP提供了功能完善的替换。JPA规范没有解决bean管理的持久化，若是您但愿实现本身的持久化，应该继续使用BMP，或者最好使用会话bean façade进行自定义持久化。

问题：命名查询能够位于JPA实体之外吗?就像在会话bean或帮助类中那样?

回答：JPA实现仅扫描实体类(和映射超类以及嵌入类)来查找命名查询。我但愿未来的JPA规范版本提供一种方式，用于将命名查询限制到一个类对象中，到那个时候，就能够认为可以在任何位置定义命名查询。

能够在orm.xml文件中定义命名查询，而后使您的持久化单元指向该orm.xml文件，JPA规范容许将任意数目的orm.xml文件合并到一块儿。

问题：JPQL支持多数据库查询吗?

回答：JPA规范并不要求实现必须只使用单个数据库(甚至实现必须使用关系数据库)。所以实现能够随意提供对多个数据库的访问。可是，据我所知，当前的JPA实现都没有这么做，除非是经过数据库方的工做来实现多数据库查询。

问题：在JPQL中，SELECT子句能够从多个实体中拉出数据吗?

回答：是的。JPQL语言容许查询聚合和投影。所以如下语句是有效的JPQL语句：

select p.name, p.contactInfo.phoneNumber from Person p
select p.address.state, avg(p.salary) from Person p group by p.address.state

问题：JPA规范是否解决了缓存问题?

回答：JPA规范仅解决给定EntityManager相关对象的事务工做集的行为。它称之为“持久化上下文”。从某些方面来说，这是一个缓存，但一般是为了保持事务一致性，而不是为了性能的缘由。

JPA规范没有解决性能缓存，如OpenJPA的 数据缓存 和 查询缓存。可是规范中的规则对这类性能缓存暗示了某些行为约束。

总而言之，JPA规范主要关注的仅是API的行为方面，而由各类实现完成大多数性能有关的调优。尽管如此，全部可靠的实现都应该拥有某种数据缓存，以做为选择。

问题：WebLogic Server 9.0仍然仅支持EJB2.0，是吗?

回答：正确。WebLogic Server 10.0是彻底支持EJB3规范的第一款BEA产品。在WebLogic Server 9中能够经过BEA Kodo产品来使用JPA。

问题：关于JPA的推荐教程是什么?

回答：Kodo文档 中提供了许多JPA教程。

问题：是否存在任何方式，用于跨全部实体表配置表前缀?

回答：JPA规范中没有提供这种方式，在OpenJPA中，能够经过建立扩展的 DBDictionary 并重写getValidTableName()方法来实现该功能。

问题：JPA是否支持惰性加载?

回答：是的。默认状况下，Collection和Map类型的字段是惰性检索的，而其余全部字段都是主动获取的。经过在字段的持久化注解中指明“fetch”属性，能够基于各个字段静态地控制该行为。

问题：是否可能经过编程修改ORM绑定(如重写orm.xml中指定的一些ORM配置)?

回答：不是经过JPA规范实现的。OpenJPA提供了一些方法，用于以编程的方式建立映射信息，而且该规范确实提供了一种方法，用于在建立EntityManager时，将特定于供应商的重写内容传递给persistence.xml中的数据。

问题：咱们正在构建一个大型应用程序，其中有350个对象坚持JPA规范。当咱们使用Kodo 4.1持久化这些对象时，它的SELECT查询最终将每一个查询的大多数表链接起来，这使得Kodo至关慢。TopLink Essentials实现仅链接少许的相关表。您对解决该问题有什么建议?

回答：我认为这与“一对一”和“多对一”字段类型的不一样默认行为有关。我猜测，若是您明确地告知Kodo对“一对一”和“多对一”字段类型执行惰性加载，就会很清楚。若是这不起做用，或者若是您但愿得到更多帮助来分析您的具体用例，请发送电子邮件到plinskey@bea.com。

问题：开发人员可使用JPA来控制表的链接方式吗?

回答：不能直接控制，而且不是经过规范实现的。可是，大多数实现可能提供了一些方式来影响如何链接。有关OpenJPA的详细信息，请参阅关于 主动fetching 的文档。

问题：在何处指定数据源?

回答：数据源一般是在persistence.xml中指定的，根据您的实现和应用服务器的默认行为，可能须要为jta-data-source和/或non-jta-data-source设置提供值。

问题：JPA规范是否计划在未来支持里程碑或双时态链(bi-temporal)?

回答：据我所知，JPA规范团队目前没有计划提供任什么时候态功能。

问题：若是抛出乐观锁定异常，能够了解哪些列发生冲突吗

回答：不能够。您能够了解哪些实例失败，但不是字段。给定失败的实例，很容易从数据库中加载新值，并进行比较。