Posted in 面试题 onNovember 14, 2016
这篇文章是摘自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
问题:你们对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规范团队目前没有计划提供任何时态功能。
问题:如果抛出乐观锁定异常,可以了解哪些列发生冲突吗
回答:不可以。您可以了解哪些实例失败,但不是字段。给定失败的实例,很容易从数据库中加载新值,并进行比较。
问题: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
问题:你们对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规范团队目前没有计划提供任何时态功能。
问题:如果抛出乐观锁定异常,可以了解哪些列发生冲突吗
回答:不可以。您可以了解哪些实例失败,但不是字段。给定失败的实例,很容易从数据库中加载新值,并进行比较。
JPA面试常见问题
声明:登载此文出于传递更多信息之目的,并不意味着赞同其观点或证实其描述。
Tags in this post...
Reply on: @reply_date@
@reply_contents@