JavaWeb面试题：Hibernate

1. 进行更新操作时为什么需先获取数据库中原数据

进行更新操作的时候，为什么一般都是需要先获取到数据库中原数据，然后再把新对象的内容进行复制，然后再执行更新操作呢？比如下面的代码(1)而不是直接代码(2)。

代码（1）内容：

// 其中Persion为一个pojo类
// 参数：currentPerson表示从controller层获取到从页面中传递过来的内容
// Service层中：
public void updatePerson(Person currentPerson){
      //获取到需要修改内容在数据库中原始的内容信息，也就是调用sesssion.load(id)这hibernate方法，也可以是get方法
      Person person = personDao.loadPerson（currentPerson.getId());
      //将传递过来的对象的属性内容进行复制到获取的对象中
      BeanUtil.copyProperties(currentPerson , person);
      //进行hibernate中的session更新操作
      personDao.updatePerson(person);
}

代码（2）内容：

// 其中Persion为一个pojo类
// 参数：currentPerson表示从controller层获取到从页面中传递过来的内容
// Service层中：
public void updatePerson(Person currentPerson){
      //进行hibernate中的session更新操作
      personDao.updatePersoncurrentPerson)
}

解答：

在上面的service层的这个更新的方法中（当然也可以是在controller层或者是strus2的方法中，只是调用的形式有变化而已），注意到了是先获取到数据库中对应的主键id的内容，然后再根据修改的内容进行的更新操作的。

当然，这个问题并不是一定会的，可以说是一种规范吧，就是能够更安全。原因就在于，在hibernate的工作机制中，对应在同一区域（Hibernate缓存区）和时间是不能够有相同主键内容的数据存在的，也就是说不能有两个相同主键的持久化类存在。

更为通俗的讲解就是，如果当前需要更新的实体，刚好的主键id对应着Hibernate缓存区中，已经存在了，那么这样就会报一个different object with the same identitifer的错误，很明显就是说存在了相同id的两个持久化类了，所以，通过先拿到当前修改id的原始内容，然后进行修改属性内容之后，再把改对象放入到更新操作中，就相当于从hibernate缓存区先取出已经存在的，然后修改了，再放回去，这样就肯定保证了只会存在一个唯一了，所以就防止不会出现上述的这个错误了。

当然，如果不进行先获取，再保存也可以，只是这样增加了安全性，所以记住，如果进行修改操作，那么就需要这样的步骤才是最安全的。

2. 解决Hibernate懒加载load出现no session的错误

这个问题其实是开发中，很经过会遇到的一个问题。之所以出现这样的问题是在于，session对象当执行了相应的crud操作之后，就会结束生命周期了，而当session接受之后，然后又访问刚获取到的对象的相应的内容，那么因为是load（）方法是进行懒加载，当真正进行使用该对象的时候，再会真正的去获取，而此时session对象已经关闭了，所以肯定就会出现上面的问题了。就代码解释就是如下的代码：

// 其中Persion为一个pojo类
// 参数：id表示从要进行获取到主键id
// Dao层中：
public void loadOpPerson(Long id){
     Person person = this.hibernateTemplate.load(Person.class , id);
    person.getName(); //执行到这就会报no session的错误
}

原理上面，我解释过了，所以，来说一下如何解决这个问题，其实很好解决，那就是扩大session的生命周期，这样不就可以么吗？所以就可以采取在web.xml中配置一个OpenSessionInViewFilter过滤器，具体代码如下：

<filter>
    <filter-name>OpenSessionInViewFilter</filter-name>
    <filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class>
</filter>

<filter-mapping>
    <filter-name>OpenSessionInViewFilter</filter-name>
    <url-pattern>*.action</url-pattern>
</filter-mapping>

注意，这个一定要配置在strus2的核心过滤器前面（如果采取的是strus2的框架，如果用的springmvc那么同理）。

3. 解决Hibernate中并发所引起的数据库内容读取问题

对于这个问题中，是非常常见的，但是Hibernate提供了很好的支持，就是通过锁机制，这就可以采取悲观锁与乐观锁的机制来解决这个问题。

悲观锁 —— 锁的粒度为数据库

悲观锁，它是对数据库而言的，数据库悲观了，他感觉每一个对他操作的程序都有可能产生并发。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。

悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

首先说一条SQL语句如下：

select * from student where name="xiaoming" for update

其实这就是一个非常依赖于数据库的悲观锁的使用，同理，Hibernate之所以也能够这样，也就是通过数据库中的锁机制来实现的。代码如下：

String hqlStr ="from Student s where s.name='xiaoming'";  
Query query = session.createQuery(hqlStr);  
query.setLockMode("s",LockMode.UPGRADE); // 加锁  
List userList = query.list();// 执行查询，获取数据

这里Hibernate通过使用数据库的 for update子句实现了悲观锁机制。

Hibernate的加锁模式有：

  • LockMode.NONE ：无锁机制。
  • LockMode.WRITE ：Hibernate在 Insert和 Update记录的时候会自动获取。
  • LockMode.READ ：Hibernate在读取记录的时候会自动获取。

以上这三种锁机制一般由 Hibernate内部使用，如Hibernate为了保证 Update过程中对象不会被外界修改，会在 save 方法实现中自动为目标对象加上 WRITE锁。

  • LockMode.UPGRADE ：利用数据库的 for update 子句加锁。
  • LockMode. UPGRADE_NOWAIT ： Oracle的特定实现，利用 Oracle的 for update nowait子句实现加锁。

上面这两种锁机制是我们在应用层较为常用的，加锁一般通过以下方法实现：

  • Criteria.setLockMode
  • Query.setLockMode
  • Session.lock

注意，只有在查询开始之前（也就是 Hiberate生成 SQL之前）设定加锁，才会真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含 for update子句的 Select SQL加载进来，所谓数据库加锁也就无从谈起。

乐观锁 —— 锁的粒度为表，而且当出现了问题之后，才采取措施

乐观锁，从名字来看，就肯定比悲观锁有着更为乐观的态度了，就是说悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（Version）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个"version"字段来实现。

乐观锁的工作原理：读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

Hibernate为乐观锁提供了三 种实现：

  1. 基于version —— 最常用
  2. 基于timestamp —— 较常用
  3. 为遗留项目添加乐观锁 —— 不常用

基于version的使用

（1）对需要进行锁控制的数据库表中，添加一个字段，名字随便，一般就叫version，类型只有为long,integer,short,timestamp,calendar，也就是只能为数字或timestamp类型。

（2）如果通过配置文件进行配置的hibernate映射文件，那么就在对应的实体映射文件中添加如下代码：

<versionname="version"  column="VERSION" type="integer" />

如果是通过注解的形式进行的hibernate实体配置，那么很简单，只需要在对应的version字段用注解@version，即可，是不是简单很多呢？

（3）在POJO实体类中，实现对于version字段的set（）和get（）方法，这个和普通的属性一样，都需要这两个方法。

基于timestamp

这个使用一样，只是需要把映射文件中的标签改一下即可，

<!--timestamp标签用于指定表示版本号的字段信息-->  
<timestamp name="version"column="version"></timestamp>

好了，下面就用一个test例子来验证一下是否有锁控制机制。

//开启两个session
Sessionsession1=sessionFactory.openSession();  
Session session2=sessionFactory.openSession();  
Student stu1=(Student)session1.createQuery("from Student s wheres.name='xiaoming'").uniqueResult();  
Student stu2=(Student)session2.createQuery("from Student s wheres.name='xiaoming'").uniqueResult();  
//首先看一下，拿出来的数据的version版本是否一致，结果是是一致，都是数据库当前的版本
System.out.println("v1="+stu1.getVersion()+"--v2="+stu2.getVersion());  
//开始第一个事务
Transactiontx1=session1.beginTransaction();  
//修改内容
stu1.setName("xiaohong"); 
//事务提交 
tx1.commit();  
//当进行了事务提交之后，也就是数据的更新操作，再看看此时两个version是否一致，结果显示version不一样了
System.out.println("v1="+stu1.getVersion()+"--v2="+stu2.getVersion());  
//同理，再将第二个事务进行提交
Transactiontx2=session2.beginTransaction();  
stu2.setName("xiaobai");  
//提交
tx2.commit();

OK,编译的时候是没有任何问题的，但是一运行就发现报了一个错，并且错误显示：

Exception in thread "main" org.hibernate.StaleObjectStateException:Row was updated or deleted by another transaction (or unsaved-value mapping wasincorrect):

其实，原因很简单，就是因为第一个事务提交对数据之后，这条数据的内容被更新，然后数据库中的版本控制字段version相比原来的版本+1，而当第二个事务再提交更新操作的时候，因为当前的数据的版本是原来的版本，而数据库中的版本比它高了，所以就认为这条数据是条无效的数据，那么结果很明显就是会发现刚才的错误。这样的话，是不是对于并发操作的问题就提供了一个很好的方法呢？

4. 什么是Hibernate的并发机制

Hibernate并发机制：

  • Hibernate的Session对象是非线程安全的,对于单个请求,单个会话,单个的工作单元(即单个事务,单个线程),它通常只使用一次, 然后就丢弃。

如果一个Session 实例允许共享的话，那些支持并发运行的,例如Http request,session beans将会导致出现资源争用。 如果在Http Session中有hibernate的Session的话,就可能会出现同步访问Http Session。只要用户足够快的点击浏览器的“刷新”, 就会导致两个并发运行的线程使用同一个Session。

  • 多个事务并发访问同一块资源,可能会引发第一类丢失更新，脏读，幻读，不可重复读，第二类丢失更新一系列的问题。

解决方案：设置事务隔离级别。

  • Serializable：串行化。隔离级别最高
  • Repeatable Read：可重复读
  • Read Committed：已提交数据读
  • Read Uncommitted：未提交数据读。隔离级别最差

设置锁：乐观锁和悲观锁。

乐观锁：使用版本号或时间戳来检测更新丢失,在的映射中设置 optimistic-lock=”all”可以在没有版本或者时间戳属性映射的情况下实现 版本检查，此时Hibernate将比较一行记录的每个字段的状态

行级悲观锁：Hibernate总是使用数据库的锁定机制，从不在内存中锁定对象！只要为JDBC连接指定一下隔 离级别，然后让数据库去搞定一切就够了。类LockMode 定义了Hibernate所需的不同的锁定级别：LockMode.UPGRADE,LockMode.UPGRADE_NOWAIT,LockMode.READ;

5. update和saveOrUpdate的区别

update()和saveOrUpdate()是用来对跨Session的PO进行状态管理的。

update()方法操作的对象必须是持久化了的对象。也就是说，如果此对象在数据库中不存在的话，就不能使用update()方法。

saveOrUpdate()方法操作的对象既可以使持久化了的，也可以使没有持久化的对象。如果是持久化了的对象调用saveOrUpdate()则会 更新数据库中的对象；如果是未持久化的对象使用此方法,则save到数据库中。

6. Hibernate的三种状态之间如何转换

在hibernate中 不同的持久化操作会导致对象的状态的改变 ，如下图所示：

  1. 瞬时状态转换为持久状态
    • 使用session对象的save()或saveOrUpdate()方法保存对象后，该对象的状态由瞬时状态转换为持久状态。
    • 使用session对象的get()或load()方法获取对象后，该对象的状态是持久状态。
  2. 持久状态转换为瞬时状态
    • 执行session对象的delete()方法后，对象由原来的持久状态变为瞬时状态，因此该对象没有与任何的数据库数据有关联。
  3. 持久状态变为游离状态
    • 执行了session对象的evict()、clear()、 close() 方法，对象由原来的持久状态变为游离态。
  4. 游离状态转换为持久状态
    • 重新获取session对象，执行session对象的update()或 saveOrUpdate()方法，由游离状态转换为持久状态，该对象再次与session关联。
  5. 游离状态转换为瞬时状态
    • 执行session的delete()方法，对象有游离状态变为瞬时状态。
    • 对瞬时状态或游离状态 的对象不再被其他对象引用时，会被Java虚拟机按照垃圾回收机制处理。

7. Hibernate的三种检索策略优缺点

立即检索：

  • 优点： 对应用程序完全透明，不管对象处于持久化状态，还是游离状态，应用程序都可以方便的从一个对象导航到与它关联的对象；
  • 缺点： 1.select语句太多；2.可能会加载应用程序不需要访问的对象白白浪费许多内存空间；
  • 立即检索:lazy=false；

延迟检索：

  • 优点： 由应用程序决定需要加载哪些对象，可以避免可执行多余的select语句，以及避免加载应用程序不需要访问的对象。因此能提高检索性能，并且能节省内存空间；
  • 缺点： 应用程序如果希望访问游离状态代理类实例，必须保证他在持久化状态时已经被初始化；
  • 延迟加载：lazy=true；

迫切左外连接检索：

  • 优点： 1对应用程序完全透明，不管对象处于持久化状态，还是游离状态，应用程序都可以方便地冲一个对象导航到与它关联的对象。2使用了外连接，select语句数目少；
  • 缺点： 1 可能会加载应用程序不需要访问的对象，白白浪费许多内存空间；2复杂的数据库表连接也会影响检索性能；
  • 预先抓取： fetch=“join”；

8. 如何在控制台查看Hibernate生成并执行的sql

在定义数据库和数据库属性的文件applicationConfig.xml里面，把hibernate.show_sql 设置为true 这样生成的SQL就会在控制台出现了。

注意：这样做会加重系统的负担，不利于性能调优。

9. Hibernate都支持哪些缓存策略

  • Read-only: 这种策略适用于那些频繁读取却不会更新的数据，这是目前为止最简单和最有效的缓存策略
  • Read/write:这种策略适用于需要被更新的数据，比read-only更耗费资源，在非JTA环境下，每个事务需要在session.close和session.disconnect()被调用
  • Nonstrict read/write: 这种策略不保障两个同时进行的事务会修改同一块数据，这种策略适用于那些经常读取但是极少更新的数据
  • Transactional: 这种策略是完全事务化得缓存策略，可以用在JTA环境下

10. sorted collection 和ordered collection的区别

sorted collection

  • 是在内存中通过Java比较器进行排序的

ordered collection

  • 是在数据库中通过order by进行排序的

对于比较大的数据集，为了避免在内存中对它们进行排序而出现 Java中的OutOfMemoryError，最好使用ordered collection。

11. Hibernate工作原理及为什么要使用

工作原理：

  1. 读取并解析配置文件
  2. 读取并解析映射信息，创建SessionFactory
  3. 打开Sesssion
  4. 创建事务Transation
  5. 持久化操作
  6. 提交事务
  7. 关闭Session
  8. 关闭SesstionFactory

为什么要使用：

  1. 对JDBC访问数据库的代码做了封装，大大简化了数据访问层繁琐的重复性代码。
  2. Hibernate是一个基于JDBC的主流持久化框架，是一个优秀的ORM实现。他很大程度的简化DAO层的编码工作。
  3. Hibernate使用Java反射机制，而不是字节码增强程序来实现透明性。
  4. Hibernate的性能非常好，因为它是个轻量级框架。映射的灵活性很出色。它支持各种关系数据库，从一对一到多对多的各种复杂关系。

12. Hibernate是如何延迟加载

当Hibernate在查询数据的时候，数据并没有存在与内存中，当程序真正对数据的操作时，对象才存在与内存中，就实现了延迟加载，他节省了服务器的内存开销，从而提高了服务器的性能。

13. 说下Hibernate的缓存机制

一级缓存：

  • Hibenate中一级缓存，也叫做session的缓存，它可以在session范围内减少数据库的访问次数！ 只在session范围有效！ Session关闭，一级缓存失效！
  • 只要是持久化对象状态的，都受Session管理，也就是说，都会在Session缓存中！
  • Session的缓存由hibernate维护，用户不能操作缓存内容； 如果想操作缓存内容，必须通过hibernate提供的evit/clear方法操作。

二级缓存：

  • 二级缓存是基于应用程序的缓存，所有的Session都可以使用。
  • Hibernate提供的二级缓存有默认的实现，且是一种可插配的缓存框架！如果用户想用二级缓存，只需要在hibernate.cfg.xml中配置即可； 不想用，直接移除，不影响代码。
  • 如果用户觉得hibernate提供的框架框架不好用，自己可以换其他的缓存框架或自己实现缓存框架都可以。
  • Hibernate二级缓存：存储的是常用的类。

14. Hibernate的查询方式有几种

  • 对象导航查询(objectcomposition)
  • HQL查询
    • 1、 属性查询
    • 2、 参数查询、命名参数查询
    • 3、 关联查询
    • 4、 分页查询
    • 5、 统计函数
  • Criteria 查询
  • SQLQuery本地SQL查询

15. 如何优化Hibernate

  • 数据库设计调整
  • HQL优化
  • API的正确使用(如根据不同的业务类型选用不同的集合及查询API)
  • 主配置参数(日志，查询缓存，fetch_size, batch_size等)
  • 映射文件优化(ID生成策略，二级缓存，延迟加载，关联优化)
  • 一级缓存的管理
  • 针对二级缓存，还有许多特有的策略

16. 谈谈Hibernate中inverse的作用

inverse属性默认是false,就是说关系的两端都来维护关系。

  • 比如Student和Teacher是多对多关系，用一个中间表TeacherStudent维护。Gp)
  • 如果Student这边inverse=”true”, 那么关系由另一端Teacher维护，就是说当插入Student时，不会操作TeacherStudent表（中间表）。只有Teacher插入或删除时才会触发对中间表的操作。所以两边都inverse=”true”是不对的，会导致任何操作都不触发对中间表的影响；当两边都inverse=”false”或默认时，会导致在中间表中插入两次关系。

如果表之间的关联关系是“一对多”的话，那么inverse只能在“一”的一方来配置！

17. Detached Object（游离对象）有什么好处

Detached Object（游离对象）可以传递到任何层直到表现层而不是用任何DTO(DataTransfer Objects)。 然后你还可以重新把游离对象赋给另外一个Session。

18. 数据库中条件查询速度很慢时如何优化

  • 建索引
  • 减少表之间的关联
  • 优化sql，尽量让sql很快定位数据，不要让sql做全表查询，应该走索引，把数据量大的表排在前面
  • 简化查询字段，没用的字段不要，已经对返回结果的控制，尽量返回少量数据

19. 什么是SessionFactory，它是线程安全么

SessionFactory 是Hibrenate单例数据存储和线程安全的，以至于可以多线程同时访问。

一个SessionFactory 在启动的时候只能建立一次。SessionFactory应该包装各种单例以至于它能很简单的在一个应用代码中储存。

20. Hibernate的五个核心接口

  • Configuration 接口：配置Hibernate，根据其启动hibernate，创建 SessionFactory 对象；
  • SessionFactory 接口：初始化Hibernate，充当数据存储源的代理，创建session 对象，sessionFactory 是线程安全的，意味着它的同一个实例可以被应用的多个线程共享，是重量级、二级缓存；
  • Session 接口：负责保存、更新、删除、加载和查询对象，是线程不安全的， 避免多个线程共享同一个session，是轻量级、一级缓存；
  • Transaction 接口：管理事务；
  • Query 和Criteria 接口：执行数据库的查询。

21. get和load区别

get()：立即查询

load()：懒加载

get如果没有找到会返回null， load如果没有找到会抛出异常。

get会先查一级缓存， 再查二级缓存，然后查数据库；load会先查一级缓存，如果没有找到，就创建代理对象， 等需要的时候去查询二级缓存和数据库。

22. merge的含义

  • 如果session中存在相同持久化标识(identifier)的实例，用用户给出的对象的状态覆盖旧有的持久实例
  • 如果session没有相应的持久实例，则尝试从数据库中加载，或创建新的持久化实例,最后返回该持久实例
  • 用户给出的这个对象没有被关联到session上，它依旧是脱管的

23. persist和save的区别

  • persist不保证立即执行，可能要等到flush；
  • persist不更新缓存；
  • save, 把一个瞬态的实例持久化标识符，及时的产生,它要返回标识符，所以它会立即执行Sql insert
  • 使用 save() 方法保存持久化对象时，该方法返回该持久化对象的标识属性值(即对应记录的主键值)；
  • 使用 persist() 方法来保存持久化对象时，该方法没有任何返回值。

24. 主键生成策略有哪些

主键类型

自然主键（主键本身就是表中的一个字段，实体中一个具体的属性）

表中已经具有某字段，并且该字段具有业务含义作为主键，称之为自然主键。

例如：在person表中的身份证号，既是唯一的，又可以单独标识一个person。

又如：在customer表中，如果把name作为主键，其前提条件必须是，每一个客户的姓名不允许为null，不允许客户重名，并且不允许修改客户姓名。尽管这也是可行的，但是不能满足不断变化的业务需求，一旦出现了允许客户重名的业务需求，就必须修改数据模型，重新定义表的主键，这给数据库的维护增加了难度。

代理主键（主键不是实体中某个具体的属性，而是一个不相关的字段）

表中原本不存在的字段，且不具备业务含义的字段作为主键，称之为代理主键。更合理的方式是使用代理主键。

主键生成策略

主键生成策略，就是每条记录录入时，主键的生成规则。Hibernate中，提供了几个内置的主键生成策略，其常用主键生成策略的名称和描述如下

代理主键

identity（主键自增）

适用于long、short或int类型主键，采用底层数据库本身提供的主键生成标识符。在DB2、MySQL、MS SQL Server、Sybase和HypersonicSQL数据库中可以使用该生成器，该生成器要求在数据库中把主键定义成为自增类型。Oracle没有自动增长

sequence（序列）

适用于long、short或int类型主键，Hibernate根据底层数据库序列生成标识符。条件是数据库支持序列。如oralce、DB、SAP DB、PostgerSQL、McKoi中的sequence，MySQL这种不支持sequence

increment（主键自增，单线程，maxID+1）

适用于long、short或int类型主键，由Hibernate提供自动递增的方式生成唯一标识符，每次增量为1。只有当没有其他进程向同一张表中插入数据时才可以使用，不能再多线程环境下使用

hilo（主键自增，高低位算法）

hilo（高低位方式high low）是hibernate中最常用的一种生成方式，需要一张额外的表保存hi的值。保存hi值的表至少有一条记录（只与第一条记录有关），否则会出现错误。跨数据库，hilo算法生成的标志只能在一个数据库中保证唯一

native（hilo+identity+sequence三选一）

根据底层数据库对自动生成标识符的能力来选择i dentity、sequence、hilo三种生成器中的一种，适合跨数据库平台开发

uuid（随机字符串作主键）

Hibernate采用128位的UUID算法来生成标识符。该算法能够在网络环境中生成唯一的字符串标识符，其UUID被编码为一个长度为32位的十六进制字符串。按照开放软件基金会(OSF)制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字

uuid长度大，占用空间大，跨数据库，不用访问数据库就生成主键值，所以效率高且能保证唯一性，移植非常方便，推荐使用。

guid（全球唯一标识符）

全球唯一标识符，也称作 UUID，是一个128位长的数字，用16进制表示。算法的核心思想是结合机器的网卡、当地时间、一个随即数来生成GUID。

Hibernate在维护主键时，先查询数据库，获得一个uuid字符串，该字符串就是主键值，该值唯一，缺点长度较大，支持数据库有限，优点同uuid，跨数据库，但是仍然需要访问数据库。注意：长度因数据库不同而不同。

需要数据库支持查询uuid，生成时需要查询数据库，效率没有uuid高，推荐使用uuid。

25. getCurrentSession和openSession的区别

  1. getCurrentSession会绑定当前线程，而openSession不会，因为我们把hibernate交给我们的spring来管理之后，我们是有事务配置，这个有事务的线程就会绑定当前的工厂里面的每一个session，而openSession是创建一个新session。
  2. getCurrentSession事务是有spring来控制的，而openSession需要我们手动开启和手动提交事务。
  3. getCurrentSession是不需要我们手动关闭的，因为工厂会自己管理，而openSession需要我们手动关闭。
  4. 而getCurrentSession需要我们手动设置绑定事务的机制，有三种设置方式，jdbc本地的Thread、JTA、第三种是spring提供的事务管理机制org.springframework.orm.hibernate4.SpringSessionContext，而且srping默认使用该种事务管理机制。

26. Hibernate中的命名SQL查询指的是什么

  • 命名查询指的是用<sql-query>标签在影射文档中定义的SQL查询，可以通过使用Session.getNamedQuery()方法对它进行调用。命名查询使你可以使用你所指定的一个名字拿到某个特定的查询。
  • Hibernate中的命名查询可以使用注解来定义，也可以使用我前面提到的xml影射问句来定义。在Hibernate中，@NameQuery用来定义单个的命名查询，@NameQueries用来定义多个命名查询。

27. 为什么在Hibernate的实体类中要提供一个无参数的构造器

每个Hibernate实体类必须包含一个 无参数的构造器, 这是因为Hibernate框架要使用Reflection API，通过调用Class.newInstance()来创建这些实体类的实例。如果在实体类中找不到无参数的构造器，这个方法就会抛出一个InstantiationException异常。

28. 可不可以将Hibernate的实体类定义为final类

可以将Hibernate的实体类定义为final类，但这种做法并不好。因为Hibernate会使用代理模式在延迟关联的情况下提高性能，如果你把实体类定义成final类之后，因为 Java不允许对final类进行扩展，所以Hibernate就无法再使用代理了， 如此一来就限制了使用可以提升性能的手段。

29. Hibernate的OpenSessionView问题

用于解决懒加载异常, 主要功能就是把 Hibernate Session 和一个请求的线程绑定在一起, 直到页面完整输出, 这样就可以保证页面读取数据的时候 Session 一直是开启的状态, 如果去获取延迟加载对象也不会报错。

问题: 如果在业务处理阶段大批量处理数据, 有可能导致一级缓存里的对象占用内存过多导致内存溢出, 另外一个是连接问题: Session 和数据库 Connection 是绑定在一起的, 如果业务处理缓慢也会导致数据库连接得不到及时的释放, 造成连接池连接不够. 所以在并发量较大的项目中不建议使用此种方式, 可以考虑使用迫切左外连接 (LEFT OUTER JOIN FETCH) 或手工对关联的对象进行初始化。

配置 Filter 的时候要放在 Struts2 过滤器的前面, 因为它要页面完全显示完后再退出。

Everything you need to prepare for your technical interview.

modified at 2019-01-28

results matching ""

    No results matching ""