批处理
使用 Hibernate 将 100,000 条记录插入到数据库的一个很天真的做法可能是这样的：
<!-- -->Session<!-- --> session <!-- -->=<!-- --> sessionFactory<!-- -->.<!-- -->openSession<!-- -->(); <!-- --> Transaction tx = session.beginTransaction(); <!-- --> for ( int i=0; i<100000; i++ ) { <!-- --> Customer customer = new Customer(.....); <!-- --> session.save(customer); <!-- --> } <!-- --> tx.commit(); <!-- --> session.close();
这段程序大概运行到 50，000 条记录左右会失败并抛出内存溢出异常（OutOfMemoryException） 。这是因为 Hibernate 把所有新插入的客户（Customer）实例在 session 级别的缓存区进行了缓存的缘故。
我们会在本章告诉你如何避免此类问题。首先，如果你要执行批量处理并且想要达到一个理想的性能，那么使用 JDBC 的批量（batching）功能是至关重要。将 JDBC 的批量抓取数量（batch size）参数设置到一个合适值（比如，10 - 50 之间）：
hibernate.jdbc.batch_size 20
注意，假若你使用了 identiy 标识符生成器，Hibernate 在 JDBC 级别透明的关闭插入语句的批量执行。 15.1. 批量插入（Batch inserts）15.2. 批量更新（Batch updates）15.3. StatelessSession（无状态 session）接口15.4. DML（数据操作语言）风格的操作（DML-style operations）HQL）来执行大批量 SQL 风格的 DML 语句的方法。
你也可能想在执行批量处理时完全关闭二级缓存：
hibernate.cache.use_second_level_cache false
但是，这不是绝对必须的，因为我们可以显式设置 CacheMode 来关闭与二级缓存的交互。
如果要将很多对象持久化，你必须通过经常的调用 flush() 以及稍后调用 clear() 来控制第一级缓存的大小。
<!-- -->Session<!-- --> session <!-- -->=<!-- --> sessionFactory<!-- -->.<!-- -->openSession<!-- -->(); <!-- --> Transaction tx = session.beginTransaction(); <!-- --> <!-- --> for ( int i=0; i<100000; i++ ) { <!-- --> Customer customer = new Customer(.....); <!-- --> session.save(customer); <!-- --> if ( i % 20 == 0 ) { //20, same as the JDBC batch size <!-- --> //flush a batch of inserts and release memory: <!-- --> session.flush(); <!-- --> session.clear(); <!-- --> } <!-- --> } <!-- --> <!-- --> tx.commit(); <!-- --> session.close();
此方法同样适用于检索和更新数据。此外，在进行会返回很多行数据的查询时，你需要使用 scroll() 方法以便充分利用服务器端游标所带来的好处。
<!-- -->Session<!-- --> session <!-- -->=<!-- --> sessionFactory<!-- -->.<!-- -->openSession<!-- -->(); <!-- --> Transaction tx = session.beginTransaction(); <!-- --> <!-- --> ScrollableResults customers = session.getNamedQuery("GetCustomers") <!-- --> .setCacheMode(CacheMode.IGNORE) <!-- --> .scroll(ScrollMode.FORWARD_ONLY); <!-- --> int count=0; <!-- --> while ( customers.next() ) { <!-- --> Customer customer = (Customer) customers.get(0); <!-- --> customer.updateStuff(...); <!-- --> if ( ++count % 20 == 0 ) { <!-- --> //flush a batch of updates and release memory: <!-- --> session.flush(); <!-- --> session.clear(); <!-- --> } <!-- --> } <!-- --> <!-- --> tx.commit(); <!-- --> session.close();
作为选择，Hibernate 提供了基于命令的 API，可以用 detached object 的形式把数据以流的方法加入到数据库，或从数据库输出。StatelessSession 没有持久化上下文，也不提供多少高层的生命周期语义。特别是，无状态 session 不实现第一级 cache，也不和第二级缓存，或者查询缓存交互。它不实现事务化写，也不实现脏数据检查。用 stateless session 进行的操作甚至不级联到关联实例。stateless session 忽略集合类（Collections）。通过 stateless session 进行的操作不触发 Hibernate 的事件模型和拦截器。无状态 session 对数据的混淆现象免疫，因为它没有第一级缓存。无状态 session 是低层的抽象，和低层 JDBC 相当接近。
<!-- -->StatelessSession<!-- --> session <!-- -->=<!-- --> sessionFactory<!-- -->.<!-- -->openStatelessSession<!-- -->(); <!-- --> Transaction tx = session.beginTransaction(); <!-- --> <!-- --> ScrollableResults customers = session.getNamedQuery("GetCustomers") <!-- --> .scroll(ScrollMode.FORWARD_ONLY); <!-- --> while ( customers.next() ) { <!-- --> Customer customer = (Customer) customers.get(0); <!-- --> customer.updateStuff(...); <!-- --> session.update(customer); <!-- --> } <!-- --> <!-- --> tx.commit(); <!-- --> session.close();
注意在上面的例子中，查询返回的 Customer 实例立即被脱管（detach）。它们与任何持久化上下文都没有关系。
StatelessSession 接口定义的 insert(), update() 和 delete() 操作是直接的数据库行级别操作，其结果是立刻执行一条 INSERT, UPDATE 或 DELETE 语句。因此，它们的语义和 Session 接口定义的 save(), saveOrUpdate() 和delete() 操作有很大的不同。
就像已经讨论的那样，自动和透明的对象/关系映射（object/relational mapping）关注于管理对象的状态。这就意味着对象的状态存在于内存，因此直接操作（使用 SQL Data Manipulation Language（DML,数据操作语言）语句 ：INSERT ,UPDATE 和 DELETE） 数据库中的数据将不会影响内存中的对象状态和对象数据。不过，Hibernate 提供通过 Hibernate 查询语言（
UPDATE 和 DELETE 语句的伪语法为：( UPDATE | DELETE ) FROM? EntityName (WHERE where_conditions)?。
要注意的事项：
-
在 FROM 子句（from-clause）中，FROM 关键字是可选的
-
在 FROM 子句（from-clause）中只能有一个实体名，它可以是别名。如果实体名是别名，那么任何被引用的属性都必须加上此别名的前缀；如果不是别名，那么任何有前缀的属性引用都是非法的。
-
不能在大批量 HQL 语句中使用 joins 连接（显式或者隐式的都不行）。不过在 WHERE 子句中可以使用子查询。可以在 where 子句中使用子查询，子查询本身可以包含 join。
-
整个 WHERE 子句是可选的。
举个例子，使用 Query.executeUpdate() 方法执行一个 HQL UPDATE语句（方法命名是来源于 JDBC 的 PreparedStatement.executeUpdate()）：
<!-- -->Session<!-- --> session <!-- -->=<!-- --> sessionFactory<!-- -->.<!-- -->openSession<!-- -->(); <!-- --> Transaction tx = session.beginTransaction(); <!-- --> String hqlUpdate = "update Customer c set c.name = :newName where c.name = :oldName"; <!-- --> // or String hqlUpdate = "update Customer set name = :newName where name = :oldName"; <!-- --> int updatedEntities = s.createQuery( hqlUpdate ) <!-- --> .setString( "newName", newName ) <!-- --> .setString( "oldName", oldName ) <!-- --> .executeUpdate(); <!-- --> tx.commit(); <!-- --> session.close();
HQL UPDATE 语句，默认不会影响更新实体的 version 或 the timestamp 属性值。这和 EJB3 规范是一致的。但是，通过使用 versioned update，你可以强制 Hibernate 正确的重置version 或者 timestamp 属性值。这通过在 UPDATE 关键字后面增加 VERSIONED 关键字来实现的。
<!-- -->Session<!-- --> session <!-- -->=<!-- --> sessionFactory<!-- -->.<!-- -->openSession<!-- -->(); <!-- --> Transaction tx = session.beginTransaction(); <!-- --> String hqlVersionedUpdate = "update versioned Customer set name = :newName where name = :oldName"; <!-- --> int updatedEntities = s.createQuery( hqlUpdate ) <!-- --> .setString( "newName", newName ) <!-- --> .setString( "oldName", oldName ) <!-- --> .executeUpdate(); <!-- --> tx.commit(); <!-- --> session.close();
注意，自定义的版本类型（org.hibernate.usertype.UserVersionType）不允许和 update versioned 语句联用。
执行一个 HQL DELETE，同样使用 Query.executeUpdate() 方法：
<!-- -->Session<!-- --> session <!-- -->=<!-- --> sessionFactory<!-- -->.<!-- -->openSession<!-- -->(); <!-- --> Transaction tx = session.beginTransaction(); <!-- --> String hqlDelete = "delete Customer c where c.name = :oldName"; <!-- --> // or String hqlDelete = "delete Customer where name = :oldName"; <!-- --> int deletedEntities = s.createQuery( hqlDelete ) <!-- --> .setString( "oldName", oldName ) <!-- --> .executeUpdate(); <!-- --> tx.commit(); <!-- --> session.close();
由 Query.executeUpdate() 方法返回的整型值表明了受此操作影响的记录数量。注意这个数值可能与数据库中被（最后一条 SQL 语句）影响了的“行”数有关，也可能没有。一个大批量 HQL 操作可能导致多条实际的SQL语句被执行，举个例子，对 joined-subclass 映射方式的类进行的此类操作。这个返回值代表了实际被语句影响了的记录数量。在那个 joined-subclass 的例子中， 对一个子类的删除实际上可能不仅仅会删除子类映射到的表而且会影响“根”表，还有可能影响与之有继承关系的 joined-subclass 映射方式的子类的表。
INSERT 语句的伪码是：INSERT INTO EntityName properties_list select_statement。要注意的是：
-
只支持 INSERT INTO ... SELECT ... 形式，不支持 INSERT INTO ... VALUES ... 形式。
properties_list 和 SQL
INSERT语句中的字段定义（column speficiation）类似。对参与继承树映射的实体而言，只有直接定义在给定的类级别的属性才能直接在 properties_list 中使用。超类的属性不被支持；子类的属性无意义。换句话说，INSERT天生不支持多态性。 -
select_statement 可以是任何合法的 HQL 选择查询，不过要保证返回类型必须和要插入的类型完全匹配。目前，这一检查是在查询编译的时候进行的，而不是把它交给数据库。注意，在Hibernate
Type间如果只是等价（equivalent）而非相等（equal），会导致问题。定义为org.hibernate.type.DateType和org.hibernate.type.TimestampType的两个属性可能会产生类型不匹配错误，虽然数据库级可能不加区分或者可以处理这种转换。 -
对 id 属性来说，insert 语句给你两个选择。你可以明确地在 properties_list 表中指定 id 属性（这样它的值是从对应的 select 表达式中获得），或者在 properties_list 中省略它（此时使用生成指）。后一种选择只有当使用在数据库中生成值的 id 产生器时才能使用；如果是“内存”中计算的类型生成器，在解析时会抛出一个异常。注意，为了说明这一问题，数据库产生值的生成器是
org.hibernate.id.SequenceGenerator（和它的子类），以及任何org.hibernate.id.PostInsertIdentifierGenerator接口的实现。这儿最值得注意的意外是org.hibernate.id.TableHiLoGenerator，它不能在此使用，因为它没有得到其值的途径。 -
对映射为
version或timestamp的属性来说，insert 语句也给你两个选择，你可以在 properties_list 表中指定（此时其值从对应的 select 表达式中获得），或者在 properties_list 中省略它（此时，使用在org.hibernate.type.VersionType中定义的seed value（种子值））。
下面是一个执行 HQL INSERT 语句的例子：
<!-- -->Session<!-- --> session <!-- -->=<!-- --> sessionFactory<!-- -->.<!-- -->openSession<!-- -->(); <!-- --> Transaction tx = session.beginTransaction(); <!-- --> String hqlInsert = "insert into DelinquentAccount (id, name) select c.id, c.name from Customer c where ..."; <!-- --> int createdEntities = s.createQuery( hqlInsert ) <!-- --> .executeUpdate(); <!-- --> tx.commit(); <!-- --> session.close();