BlogJava-Ericzhang5231-文章分类-Hibernate

（转）Spring事务传播机制解惑

Eric5231 — Sat, 05 Apr 2008 04:45:00 GMT

Spring事务传播机制解惑

概述

当我们调用一个基于Spring的Service接口方法（如UserService#addUser()）时，它将运行于Spring管理的事务环境中，Service接口方法可能会在内部调用其它的Service接口方法以共同完成一个完整的业务操作，因此就会产生服务接口方法嵌套调用的情况，Spring通过事务传播行为控制当前的事务如何传播到被嵌套调用的目标服务接口方法中。

事务传播是Spring进行事务管理的重要概念，其重要性怎么强调都不为过。但是事务传播行为也是被误解最多的地方，在本文里，我们将详细分析不同事务传播行为的表现形式，掌握它们之间的区别。

事务传播行为种类

Spring在TransactionDefinition接口中规定了7种类型的事务传播行为，它们规定了事务方法和事务方法发生嵌套调用时事务如何进行传播：

表1事务传播行为类型

事务传播行为类型	说明
PROPAGATION_REQUIRED	如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是最常见的选择。
PROPAGATION_SUPPORTS	支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY	使用当前的事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW	新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED	以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER	以非事务方式执行，如果当前存在事务，则抛出异常。
PROPAGATION_NESTED	如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作。

当使用PROPAGATION_NESTED时，底层的数据源必须基于JDBC 3.0，并且实现者需要支持保存点事务机制。

几种容易引起误解的组合事务传播行为

当服务接口方法分别使用表1中不同的事务传播行为，且这些接口方法又发生相互调用的情况下，大部分组合都是一目了然，容易理解的。但是，也存在一些容易引起误解的组合事务传播方式。

下面，我们通过两个具体的服务接口的组合调用行为来破解这一难点。这两个服务接口分别是UserService和ForumService，UserSerice有一个addCredits()方法，ForumSerivce#addTopic()方法调用了UserSerice#addCredits()方法，发生关联性服务方法的调用：

public class ForumService {

private UserService userService;

public void addTopic(){①调用其它服务接口的方法

//add Topic…

userService.addCredits();②被关联调用的业务方法

}

嵌套调用的事务方法

对Spring事务传播行为最常见的一个误解是：当服务接口方法发生嵌套调用时，被调用的服务方法只能声明为PROPAGATION_NESTED。这种观点犯了望文生义的错误，误认为PROPAGATION_NESTED是专为方法嵌套准备的。这种误解遗害不浅，执有这种误解的开发者错误地认为：应尽量不让Service类的业务方法发生相互的调用，Service类只能调用DAO层的DAO类，以避免产生嵌套事务。

其实，这种顾虑是完全没有必要的，PROPAGATION_REQUIRED已经清楚地告诉我们：事务的方法会足够“聪明”地判断上下文是否已经存在一个事务中，如果已经存在，就加入到这个事务中，否则创建一个新的事务。

依照上面的例子，假设我们将ForumService#addTopic()和UserSerice#addCredits()方法的事务传播行为都设置为PROPAGATION_REQUIRED，这两个方法将运行于同一个事务中。

为了清楚地说明这点，可以将Log4J的日志设置为DEBUG级别，以观察Spring事务管理器内部的运行情况。下面将两个业务方法都设置为PROPAGATION_REQUIRED，Spring所输出的日志信息如下：

Using transaction object

[org.springframework.jdbc.datasource.DataSourceTransactionManager$DataSourceTransactionObject@e3849c]

①为ForumService#addTopic()新建一个事务

Creating new transaction with name [com.baobaotao.service.ForumService.addTopic]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT

Acquired Connection [org.apache.commons.dbcp.PoolableConnection@dc41c5] for JDBC transaction

Switching JDBC Connection [org.apache.commons.dbcp.PoolableConnection@dc41c5] to manual commit

Bound value [org.springframework.jdbc.datasource.ConnectionHolder@ee1ede] for key [org.apache.commons.dbcp.BasicDataSource@4204] to thread [main]

Initializing transaction synchronization

Getting transaction for [com.baobaotao.service.ForumService.addTopic]

Retrieved value [org.springframework.jdbc.datasource.ConnectionHolder@ee1ede] for key [org.apache.commons.dbcp.BasicDataSource@4204] bound to thread [main]

Using transaction object [org.springframework.jdbc.datasource.DataSourceTransactionManager$DataSourceTransactionObject@8b8a47]

②UserService#addCredits()简单地加入到已存在的事务中（即①处创建的事务）

Participating in existing transaction

Getting transaction for [com.baobaotao.service.UserService.addCredits]

Completing transaction for [com.baobaotao.service.UserService.addCredits]

Completing transaction for [com.baobaotao.service.ForumService.addTopic]

Triggering beforeCommit synchronization

Triggering beforeCompletion synchronization

Initiating transaction commit

③调用底层Connection#commit()方法提交事务

Committing JDBC transaction on Connection [org.apache.commons.dbcp.PoolableConnection@dc41c5]

Triggering afterCommit synchronization

Triggering afterCompletion synchronization

Clearing transaction synchronization

嵌套事务

将ForumService#addTopic()设置为PROPAGATION_REQUIRED时，UserSerice#addCredits()设置为PROPAGATION_REQUIRED、PROPAGATION_SUPPORTS、PROPAGATION_MANDATORY时，运行的效果都是一致的（当然，如果单独调用addCredits()就另当别论了）。

当addTopic()运行在一个事务下（如设置为PROPAGATION_REQUIRED），而addCredits()设置为PROPAGATION_NESTED时，如果底层数据源支持保存点，Spring将为内部的addCredits()方法产生的一个内嵌的事务。如果addCredits()对应的内嵌事务执行失败，事务将回滚到addCredits()方法执行前的点，并不会将整个事务回滚。内嵌事务是内层事务的一部分，所以只有外层事务提交时，嵌套事务才能一并提交。

嵌套事务不能够提交，它必须通过外层事务来完成提交的动作，外层事务的回滚也会造成内部事务的回滚。

嵌套事务和新事务

PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED也是容易混淆的两个传播行为。PROPAGATION_REQUIRES_NEW 启动一个新的、和外层事务无关的“内部”事务。该事务拥有自己的独立隔离级别和锁，不依赖于外部事务，独立地提交和回滚。当内部事务开始执行时，外部事务将被挂起，内务事务结束时，外部事务才继续执行。

由此可见， PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大区别在于：PROPAGATION_REQUIRES_NEW 将创建一个全新的事务，它和外层事务没有任何关系，而 PROPAGATION_NESTED 将创建一个依赖于外层事务的子事务，当外层事务提交或回滚时，子事务也会连带提交和回滚。

其它需要注意问题

以下几个问题值得注意：

1) 当业务方法被设置为PROPAGATION_MANDATORY时，它就不能被非事务的业务方法调用。如将ForumService#addTopic()设置为PROPAGATION_MANDATORY，如果展现层的Action直接调用addTopic()方法，将引发一个异常。正确的情况是：addTopic()方法必须被另一个带事务的业务方法调用（如ForumService#otherMethod()）。所以PROPAGATION_MANDATORY的方法一般都是被其它业务方法间接调用的。

2) 当业务方法被设置为PROPAGATION_NEVER时，它将不能被拥有事务的其它业务方法调用。假设UserService#addCredits()设置为PROPAGATION_NEVER，当ForumService# addTopic()拥有一个事务时，addCredits()方法将抛出异常。所以PROPAGATION_NEVER方法一般是被直接调用的。

3)当方法被设置为PROPAGATION_NOT_SUPPORTED时，外层业务方法的事务会被挂起，当内部方法运行完成后，外层方法的事务重新运行。如果外层方法没有事务，直接运行，不需要做任何其它的事。

小结

在Spring声明式事务管理的配置中，事务传播行为是最容易被误解的配置项，原因在于事务传播行为名称（如PROPAGATION_NESTED：嵌套式事务）和代码结构的类似性上（业务类方法嵌套调用另一个业务类方法）。这种误解在很多Spring开发者中广泛存在，本文深入讲解了Spring事务传播行为对业务方法嵌套调用的真实影响，希望能帮助读者化解对事务传播行为的困惑。

Eric5231 2008-04-05 12:45 发表评论

（转）Spring事务传播机制解惑

Eric5231 — Sat, 05 Apr 2008 04:43:00 GMT

Spring事务传播机制解惑

概述

事务传播行为种类

Spring在TransactionDefinition接口中规定了7种类型的事务传播行为，它们规定了事务方法和事务方法发生嵌套调用时事务如何进行传播：

表1事务传播行为类型

事务传播行为类型	说明
PROPAGATION_REQUIRED	如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是最常见的选择。
PROPAGATION_SUPPORTS	支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY	使用当前的事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW	新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED	以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER	以非事务方式执行，如果当前存在事务，则抛出异常。
PROPAGATION_NESTED	如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作。

当使用PROPAGATION_NESTED时，底层的数据源必须基于JDBC 3.0，并且实现者需要支持保存点事务机制。

几种容易引起误解的组合事务传播行为

public class ForumService {

private UserService userService;

public void addTopic(){①调用其它服务接口的方法

//add Topic…

userService.addCredits();②被关联调用的业务方法

}

嵌套调用的事务方法

依照上面的例子，假设我们将ForumService#addTopic()和UserSerice#addCredits()方法的事务传播行为都设置为PROPAGATION_REQUIRED，这两个方法将运行于同一个事务中。

Using transaction object

[org.springframework.jdbc.datasource.DataSourceTransactionManager$DataSourceTransactionObject@e3849c]

①为ForumService#addTopic()新建一个事务

Creating new transaction with name [com.baobaotao.service.ForumService.addTopic]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT

Acquired Connection [org.apache.commons.dbcp.PoolableConnection@dc41c5] for JDBC transaction

Switching JDBC Connection [org.apache.commons.dbcp.PoolableConnection@dc41c5] to manual commit

Bound value [org.springframework.jdbc.datasource.ConnectionHolder@ee1ede] for key [org.apache.commons.dbcp.BasicDataSource@4204] to thread [main]

Initializing transaction synchronization

Getting transaction for [com.baobaotao.service.ForumService.addTopic]

Retrieved value [org.springframework.jdbc.datasource.ConnectionHolder@ee1ede] for key [org.apache.commons.dbcp.BasicDataSource@4204] bound to thread [main]

Using transaction object [org.springframework.jdbc.datasource.DataSourceTransactionManager$DataSourceTransactionObject@8b8a47]

②UserService#addCredits()简单地加入到已存在的事务中（即①处创建的事务）

Participating in existing transaction

Getting transaction for [com.baobaotao.service.UserService.addCredits]

Completing transaction for [com.baobaotao.service.UserService.addCredits]

Completing transaction for [com.baobaotao.service.ForumService.addTopic]

Triggering beforeCommit synchronization

Triggering beforeCompletion synchronization

Initiating transaction commit

③调用底层Connection#commit()方法提交事务

Committing JDBC transaction on Connection [org.apache.commons.dbcp.PoolableConnection@dc41c5]

Triggering afterCommit synchronization

Triggering afterCompletion synchronization

Clearing transaction synchronization

嵌套事务

嵌套事务不能够提交，它必须通过外层事务来完成提交的动作，外层事务的回滚也会造成内部事务的回滚。

嵌套事务和新事务

其它需要注意问题

以下几个问题值得注意：

小结

Eric5231 2008-04-05 12:43 发表评论

Transaction always commits even if marked readOnly

Eric5231 — Sat, 05 Apr 2008 04:36:00 GMT

Let me first of all state the expected behavior: Silently marking a transaction as rollback-only through a setRollbackOnly call will work as long as you do it at the *outermost* transaction level. If you do it within an inner transaction scope, the outer transaction will see this as a "global" rollback-only and throw an UnexpectedRollbackException - since the code in the outer transaction did not explicitly ask for a rollback, so needs to be notified.

So in your scenario, I would assume that you do the setRollbackOnly within an inner transaction scope. Since you're using , this could mean that your pointcut is too broad and applies transaction demarcation at multiple levels: for example, at the Controller level as well as at the service level, with the setRollbackOnly call happening in a service - this would lead to an UnexpectedRollbackException at the Controller level.

That said, I would actually argue that you should virtually never be using a programmatic setRollbackOnly call in the first place, or more specifically, a rollback without exception thrown to the caller. This usually indicates inappropriate transaction scopes.

In particular, web data binding should *not* happen within a transaction. Rather, perform data binding without transaction first, then start transactions at the service level *once you decided to process the bound data*, with the bound data brought into the transaction through a merge operation. This way, validation errors don't require a transaction rollback in the first place...

Aside from avoiding programmatic setRollbackOnly calls in your application code, the above approach to validation and transactions also avoids excessive rollbacks in your transaction statistics. Such rollbacks for frequent and perfectly normal user interactions should in particular be avoided in administered environments like a J2EE server installation - with transaction monitoring and (potentially) escalation messages generated for rollbacks.

Eric5231 2008-04-05 12:36 发表评论

利用ThreadLocal管理session

Eric5231 — Thu, 13 Mar 2008 09:04:00 GMT

在利用Hibernate开发DAO模块时，我们和Session打的交道最多，所以如何合理的管理Session，避免Session的频繁创建和销毁，对于提高系统的性能来说是非常重要的，以往是通过eclipse的插件来自动完成这些代码的，当然效果是不错的，但是总是觉得不爽(没有读懂那些冗长的代码)，所以现在打算自己实现Session管理的代码。

我们知道Session是由SessionFactory负责创建的，而SessionFactory的实现是线程安全的，多个并发的线程可以同时访问一个SessionFactory并从中获取Session实例，那么Session是否是线程安全的呢？很遗憾，答案是否定的。 Session中包含了数据库操作相关的状态信息，那么说如果多个线程同时使用一个Session实例进行CRUD，就很有可能导致数据存取的混乱，你能够想像那些你根本不能预测执行顺序的线程对你的一条记录进行操作的情形吗？

在Session的众多管理方案中，我们今天来认识一种名ThreadLocal模式的解决方案。

早在Java1.2推出之时，Java平台中就引入了一个新的支持：java.lang.ThreadLocal，给我们在编写多线程程序时提供了一种新的选择。ThreadLocal是什么呢？其实ThreadLocal并非是一个线程的本地实现版本，它并不是一个Thread，而是 thread local variable(线程局部变量)。也许把它命名为ThreadLocalVar更加合适。线程局部变量(ThreadLocal)其实的功用非常简单，就是为每一个使用某变量的线程都提供一个该变量值的副本，是每一个线程都可以独立地改变自己的副本，而不会和其它线程的副本冲突。从线程的角度看，就好像每一个线程都完全拥有一个该变量。

ThreadLocal是如何做到为每一个线程维护变量的副本的呢？其实实现的思路很简单，在ThreadLocal类中有一个Map，用于存储每一个线程的变量的副本。比如下面的示例实现(为了简单，没有考虑集合的泛型)：

public  class  ThreadLocal  {

            private  Map  values  =  Collections.synchronizedMap(new  HashMap());

            public  Object  get()  {

            Thread  currentThread  =  Thread.currentThread();  

            Object  result  =  values.get(currentThread);  

            if(result  ==  null&&!values.containsKey(currentThread))  {

            result  =  initialValue();

            values.put(currentThread,  result);  

            }

            return  result;  

            }

            public  void  set(Object  newValue)  {

            values.put(Thread.currentThread(),  newValue);

            }

            public  Object  initialValue()  {

            return  null;  

            }

            }

那麽具体如何利用ThreadLocal来管理Session呢？Hibernate官方文档手册的示例之中，提供了一个通过ThreadLocal维护Session的好榜样：

public  class  HibernateUtil  {

            public  static  final  SessionFactory  sessionFactory;

            static  {

            try  {

            sessionFactory  =  new  Configuration().configure().buildSessionFactory();

            } catch (Throwable  ex) {

            throw  new  ExceptionInInitializerError(ex);

            }

            }

            public static final ThreadLocalsession=new ThreadLocal();

            public  static  Session  currentSession()  throws  HibernateException  {

            Session  s  =  session.get();

            if(s  ==  null)  {

            s  =  sessionFactory.openSession();

            session.set(s);

            }

            return  s;

            }

            public  static  void  closeSession()  throws  HibernateException  {

            Session  s  =  session.get();

            if(s  !=  null)  {

            s.close();

            }

            session.set(null);

            }

            }

只要借助上面的工具类获取Session实例，我们就可以实现线程范围内的Session共享，从而避免了线程中频繁的创建和销毁Session实例。当然，不要忘记在用完后关闭Session。写到这里，想再多说一些，也许大多数时候我们的DAO并不会涉及到多线程的情形，比如我们不会将DAO的代码写在Servlet之中，那样不是良好的设计，我自己通常会在service层的代码里访问DAO的方法。但是我还是建议采用以上的工具类来管理 Session，毕竟我们不能仅仅考虑今天为自己做什么，还应该考虑明天为自己做什么！

Eric5231 2008-03-13 17:04 发表评论

Spring的Hibernate事务管理

Eric5231 — Fri, 07 Mar 2008 02:13:00 GMT

Spring声明式事务让我们从复杂的事务处理中得到解脱。使得我们再也无需要去处理获得连接、关闭连接、事务提交和回滚等这些操作。再也无< font color="#ff0000">需要我们在与事务相关的方法中处理大量的try…catch…finally代码< /font>。
我们在使用Spring声明式事务时，有一个非常重要的概念就是事务属性。事务属性通常由事务的传播行为，事务的隔离级别，事务的超时值和事务只读标志组成。我们在进行事务划分时，需要进行事务定义，也就是配置事务的属性。
Spring 在>TransactionDefinition 接口中定义这些属性,以供PlatfromTransactionManager使用, PlatfromTransactionManager是spring事务管理的核心接口。
代码
TransactionDefinition publicinterfaceTransactionDefinition {
intgetPropagationBehavior();
intgetIsolationLevel();
intgetTimeout();
booleanisReadOnly();
}
getTimeout()方法，它返回事务必须在多少秒内完成。
isReadOnly(),事务是否只读，事务管理器能够根据这个返回值进行优化，确保事务是只读的。
getIsolationLevel()方法返回事务的隔离级别，事务管理器根据它来控制另外一个事务可以看到本事务内的哪些数据。

在TransactionDefinition接口中定义了五个不同的事务隔离级别:

1) ISOLATION_DEFAULT 这是一个 PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别.另外四个与JDBC的隔离级别相对应 < br /> 2) ISOLATION_READ_UNCOMMITTED这是事务最低的隔离级别，它充许别外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻像读。
3) ISOLATION_READ_COMMITTED 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。这种事务隔离级别可以避免脏读出现，但是可能会出现不可重复读和幻像读。
4) ISOLATION_REPEATABLE_READ 这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)

在TransactionDefinition接口中定义了七个事务传播行为:
1) < span style="color: #000000;"> PROPAGATION_REQUIRED 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务;
2) PROPAGATION_SUPPORTS 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行;
3) PROPAGATION_MANDATORY 如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异;
4)PROPAGATION_REQUIRES_NEW 总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起;
5) PROPAGATION_NOT_SUPPORTED总是非事务地执行，并挂起任何存在的事务;
6) PROPAGATION_NEVER总是非事务地执行，如果存在一个活动事务，则抛出异常;
7) PROPAGATION_NESTED如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务, 则按 TransactionDefinition.PROPAGATION_REQUIRED 属性执行;

Eric5231 2008-03-07 10:13 发表评论

Hibernate的Load和get方法区别

Eric5231 — Fri, 07 Mar 2008 01:55:00 GMT

1.读取时机不同（当lazy=true的时候）
    load是采用延迟机制(load语句不读库，等使用非主键时才去读库)，而get不采用延迟机制(get语句时马上读库)；

2.搜索不到数据时的情况
    当搜索的数据不存在的时候，load依然会返回一个对象，在你使用该对象的非主键数据时，会抛出异常；
    当搜索的数据不存在的时候，get会返回一个null；

备注：网上看来说load比get更节省资源；
    我做过一个例子，即两个线程，1号线程把数据读出来，把session关掉。过几秒2号线程也去读相同的记录，这时2号线程并没有搜索库(没有显示出HQL语句)，不管你用load还是get
    结论：我觉得它们两个都有使用到缓存，至于更深入的我没有去研究了

Eric5231 2008-03-07 09:55 发表评论

第十三章管理Hibernate的缓存

Eric5231 — Tue, 19 Feb 2008 09:34:00 GMT

Session缓存其实就是一块内存空间,在这个内存空间中存放了互相关联的Java对象,Session负责根据持久化对象的状态变化来同步更新数据库.Session的缓存是内置的,不能被卸载,也被称为Hibernate的第一级缓存,此外SessionFactory有一个内置的缓存和一个外置的缓存,其中外置的缓存是可插拔的缓存插件,也被称为Hibernate的第二级缓存,在默认情况下,SessionFactory不会启动这个缓存插件.

缓存的范围和缓存的并发访问策略
1.持久层的缓存范围
   事务范围:   缓存只能被当前事务访问,缓存的生命周期依赖于事务的生命周期.每个事务都有独自的缓存
   进程范围: 缓存被进程内的所有事务共享,缓存的生命周期依赖于进程的生命周期. 因为进程的事务有可能并发访问缓存,所以必须对缓存采取必要的事务隔离机制;
   群集范围: 在群集环境中, 缓存被同一个机器或多个机器上的多个进程共享. 缓存中的数据被复制到集群环境中的每个进程节点,进程之间通过远程通信来保证缓存中数据的一致性,

缓存中的数据通常采用对象的散装数据形式;
2.缓存并发访问策略
   由上可见, 进程范围或群集范围缓存,即第二级缓存,会出现并发问题.对第二级缓存可以设定以下四种类型的并发访问策略,每一个策略对应一种事务隔离级别.
   1) 事务型:   仅仅在受管理环境中适用,对于经常被读但是很少被修改的数据,可以防止脏读和不可重复读的并发问题;
   2)读写型:   仅仅在非群集的环境中适用,对于经常被读但是很少被修改的数据,可以防止脏读;
   3)非严格读写型: 不保证缓存与数据库中数据的一致性,对于极少被修改,并且允许偶尔脏读的数据,可以采用这种策略;
   4)只读型: 对于从来不会被修改的数据,如参考数据,可以使用这个策略;

只有符合以下条件的数据才适合于存放到第二级缓存中:
   1) 很少被修改的数据;
   2) 不是很重要的数据,允许出现偶尔的并发问题;
   3)不会被并发访问的数据;
   4)参考数据;

Hibernate的二级缓存SessionFactory是进程范围或群集范围的缓存,因此需要采用适当的并发访问策略,提供事务隔离级别,而且可以在每个类或每个集合的粒度上配置第二级缓存.缓存适配器(Cache Provider)用于把具体的缓存实现软件于Hibernate集成.Hibernate还为查询结果提供了一个查询缓存,它依赖于第二级缓存.

管理Hibernate的第一级缓存
   Session为应用程序提供了两个管理缓存方法evict(Object o)和clear()
       evict(Object o) : 从缓存中清除参数指定的持久化对象;(适用于不希望session'按照该对象的状态变化来同步更新数据库和批量更新或批量删除的场合)
       clear(): 清空缓存中所有持久化对象
*对于更好的批量更新或者批量删除的场合应该直接通过JDBC API访问数据库的过程, 执行SQL语句来减少Hibernate API的多次sql执行, 或者调用相关的存储过程. 这个时候还得注意

Transaction接口来声明事务边界;

管理Hibernate的第二级缓存
   由于第二级缓存是可配置的插件,Hibernate允许选用以下类型的缓存插件:
   1) EHCache: 进程范围内的缓存, 对Hibernate的查询缓存提供了支持;(net.sf.hibernate.cache.EhCacheProvider EHCache插件的适配器)
   2) OpenSymphony OSCache: 进程范围内的缓存,提供了丰富的缓存数据过期策略,对Hibernate的查询缓存提供了支持;(net.sf.hibernate.cache,OSCacheProvider OSCache插件

的适配器);
   3) SwarmCache: 群集范围的缓存,但不支持Hibernate的查询缓存;(net.sf.hibernate.cache.SwarmCacheProvider SwarmCache插件的适配器)
   4) JBossCache: 群集范围内的缓存,支持事务并发访问策略,对Hibernate的查询缓存提供了支持;(net.sf.hibernate,cache.TreeCacheProvider JBossCache插件的适配器)

配置第二级缓存主要包含以下步骤:
   1) 在各个映射文件中为持久化类设置第二级缓存后者在Hibernate的配置文件hibernate.cfg.xml中集中设置第二级缓存,设置它的命名缓存的并发访问策略;
   2)选择合适的缓存插件,手工编辑配置文件,为每个命名缓存设置数据过期策略;



       ...

*如果只在category中配置cache,当调用category.getItems().iterate()方法时,Hibernate只会把items集合中的元素存放到缓存中,此时Hibernate仅仅把与Category关联的Item对象的OID存放

到缓存中.如果希望把整个Item对象散装数据存入缓存,应该在Item.hbm.xml文件中设置cache元素

***************************************************************************************************************************************************
在默认情况下,Session会在下面的时间点清理缓存.
   1) 当应用程序调用net.sf.hibernate.Transaction的commit()方法的时候,commit()方法先清理缓存, 然后再向数据库提交事务;
   2) 当应用程序调用Session的find()或者iterate()时, 如果缓存中持久化对象的属性发生了变化, 就会先清理缓存, 以保证查询结果能反映持久化对象的最新状态;
   3) 当应用程序显式调用Session的flush()方法的时候;

1. Session的save()方法
   save方法并不立即执行SQL insert语句, 只有当Session清理缓存的时, 才会执行SQL insert语句.如果在save()方法之后, 又修改了持久化对象的属性, 这会使得Session在清理缓

存时, 额外执行SQL update语句.
2. Session的update()方法
   update方法会生成或调用一个计划的update语句,并且Session只有在清理缓存的时候才会执行update语句,在执行时才会把Customer对象当前的属性值组装到update语句中.
**通过update()方法使游离对象被一个Session关联,即使没有修改Customer对象的任何属性,Session在清理缓存时也会执行由update()方法计划的update语句. 如果希望Session仅仅当修

改了Customer对象的属性时, 才执行update语句, 可以把映射文件中元素的select-before-update设为true, 该属性的默认值为false;
**当update()方法关联一个游离对象时, 如果在Session的缓存中已经存在相同OID的持久化对象,会抛出异常.
3. Session的saveOrUpdate()方法
   saveOrUpdate()方法同时包含了save()与update()方法的功能, 如果传入的参数是临时对象就调用save()方法; 如果传入的参数是游离对象, 就调用update()方法; 如果传入的参数

是持久化对象, 那就直接返回.
4. Session的load()和get()方法
   Session的load()和get()方法都能根据给定的OID从数据库中加载一个持久化对象, 这两个方法的区别在于: 当数据库中不存在与OID对应的记录时, load()方法抛出

net.sf.hibernate.ObjectNotFoundException异常,而get()返回null.
5. Session的delete()方法
   如果传入的参数是持久化对象, Session就计划执行一个delete语句. 如果传入的参数是游离对象, 先使游离对象被Session关联, 使它变为持久化对象, 然后计划执行一个delete语

句. Session只有在清理缓存的时候才会执行delete语句.
   该方法也能删除多个对象, 但不推荐,效率低.如 session.delete("from Customer as c where c.id>8");

Eric5231 2008-02-19 17:34 发表评论

第十一章 Hibernate的检索方式

Eric5231 — Mon, 18 Feb 2008 08:11:00 GMT

HQL:
CreateQuery()
   Query query = session.createQuery("from Customer as c where c.name=:customerName and c.age=:customerAge");
   query.setString("customerName","Tom");
   query.setInteger("customerAge",21);

createQuery()支持方法链编程风格

QBC:(Criteria,Criterion,Expression)
   Criteria criteria = session.createCriteria(Customer.class);
   Criterion criterion1 = Expression.like("name", "T%");
   Criterion criterion2 = Expression.like("age", new Integer(21));
   Criteria = criteria.add(criterion1).add(criterion2);
   List result = criteria.list();

HQL&&QBC支持多态和继承查询
HQL&&QBC支持排序和分页
   HQL: Query query = session.createQuery("from Customer c order by c. name asc, c.age desc"); //排序
               query.setFirstResult(10); //设定从对象开始检索起始位置为0
                              query.setMaxResults(10); //设定一次最多检索出的对象数目
   QBC: Criteria criteria = session.createCriteria(Customer.class);
               criteria.addOrder(Order.asc("name"));
               criteria.addOrder(Order.desc("age"));
               criteria.setFirstResult(0); //设定从对象开始检索起始位置为0
               criteria.setMaxResult(10); //设定一次最多检索出的对象数目

参数绑定能有效避免一些安全漏洞

HIbernate还能在xml文件里面配置HQL或者SQL本地查询语句:
   //for HQL

         ...

//for SQL

   在程序中使用getNamedQuery()方法获得查询语句:
       Query query = session.getNamedQuery("findCustomersByName");
       query.setString("name",name);
       List result = query.list();

内连接：利用内连接可获取两表的公共部分的记录Select * from A JOIN B ON A.Aid=B.Bnameid

当查询的只是对象的部分属性的时候, 可以采用动态实例化查询结果,把实体的部分属性封装为一个javabean临时对象,不需要创建对象-关系映射文件
   package mypack;
   import java.io.Serializable;
   public class CustomerRow implements Serializable{
       private Long id;
       private String name;
       private String orderNumber;

       public CustomerRow(Long id, String name, String orderNumber){
           this,id=id;
           ...
       }
       ...
        此处省略id,name和orderNumber属性的get和set方法
       ...
   }
   在程序中可以结合HQL查询语句这样使用,
   Iterator it = session.createQuery("select new mypack.CustomerRow(c.id,c.name,o.orderNumber)'
           +'from Customer c join c,orders o where o,orderNumber like 'T%'").list().iterator();
   此外如果结果集只有一个结果,可以用uniqueResult()方法
   Object[] obj = (Object[])session.createQuery("select max(c.age),min(c.age) from Customer c").uniqueResult();
   Integer maxAge = (Integer) obj[0];
   Integer minAge = (Integer) obj[1];

结果集中可以通过利用set和sql的distinct去掉

动态查询适宜用QBC检索方式,可以简化编程:
   public List findCustomers (String name, int age) throws HibernateException{
       Criteria criteria = session,createCriteria(Customer,class);
       if(name != null){
           criteria.add(Expression.like("name",nam.toLowerCase(),MactchMode.ANYWHWERE));
       }
       if(age!=0){
           crteria.add(Expression.eq("age",new Integer(age)));
       }

       return criteria.list();

   }

集合过滤: 当orders集合由于使用延迟检索策略而没有在开始被初始化,当调用get***().iterator()方法初始化的时候不能对这个集合进行排序或者条件过滤,通过使

用集合过滤就能解决这个问题:
   List result = session.createFilter(customer.getOrders(), "where this.price>100 order by this.price") .list();
集合过滤除了用于为集合排序或设置约束条件,还可以:
   1) 为集合分页
   List result = session.createFilter(customer.getOrders(), "order by this,price asc")
       .setFirstResult(10)
       .setMaxResult(50)
       .list();
   2)只选择集合的某个属性
   List result = session.createFilter(customer.getOrders(), "select this.orderNumber").list();

Eric5231 2008-02-18 16:11 发表评论

第九章 Hibernate的映射类型

Eric5231 — Thu, 24 Jan 2008 07:57:00 GMT

Hibernate映射类型分为两种：内置的映射类型和客户化映射类型。内置映射类型负责把一些常见的Java类型映射到相应的SQL类型；此外，Hibernate还允许用户实现UserType或CompositeUserType接口，来灵活地定制客户化映射类型

1.内置映射类型
1).Java基本类型的Hibernate映射类型

Java类型	Hibernate映射类型	标准SQL类型	大小和取值范围
int/Integer	int/integer	INTEGER	4Byte
long/Long	long	BIGINT	8Byte
short/Short	short	SAMLLINT	2Byte
byte/Byte	byte	TINYINT	1Byte
float/Float	float	FLOAT	4Byte
double/Double	double	DOUBLE	8Byte
BigDecimal	big_decimal	NUMBERIC	Numeric(8,2)
char/Character/String	character	CHAR(1)	定长字符
String	string	VARCHAR	变长字符
boolean/Boolean	boolean	BIT	布尔类型
boolean/Boolean	yes/no	CHAR(1)('Y'/'N')	布尔类型
boolean/Boolean	true/false	CHAR(1)('T'/'F')	布尔类型

2). Java时间和日期类型的Hibernate映射类型

Java类型	Hibernate映射类型	标准SQL类型	描述
java.util.Date/java.sql.Date	date	DATE	日期，yyyy-mm-dd
java.util.Date/java.sql.TIme	time	TIME	时间，hh：mm：ss
java.util.Date/java.sql.Timestamp	timestamp	TIMESTAMP	时间戳，yyyymmddhhmmss
java.util.Calendar	calendar	TIMESTAMP	同上
java.util.Calendar	calendar_date	DATE	日期，yyyy-mm-dd

* 当程序类型为java.sql.Timestamp, 数据库中表属性类型为timestamp的情况下，即使用户以空值插入数据，数据库系统仍然会自动填充timestamp的值

3). Java 大对象类型的Hibernate映射类型

Java类型	Hibernate映射类型	标准SQL类型	MySql类型	Oracle类型
byte[]	binary	VARBINARY/BLOB	BLOB	BLOB
String	text	CLOB	TEXT	CLOB
serializable	实现serializable接口的一个java类	VARBINARY/BLOB	BLOB	BLOB
java.sql.Clob	clob	CLOB	TEXT	CLOB
java.sql.Blob	blob	BLOB	BLOB	BLOB

* 在应用程序中通过Hibernate来保存java.sql.Clob或者java.sql.Blob实例时，必须包含两个步骤：
a. 在一个数据库事务中先保存一个空的Blob或Clob实例；b. 接着锁定这条记录，更新在步骤（1）中保存的Blob或Clob实例，把二进制数据或长文本数据写到Blob或Clob实例中。

1
2Session session = sessionFactory.openSession();
3Transaction tx = session.beginTransaction();
4Customer customer = new Customer();
5customer.setDescription(Hibernate.createClob("")); //先保存一个空的clob
6session.save(customer);
7session.flush();
8//锁定这条记录
9session.refresh(customer,LockMode.UPGRADE);
10oracle.sql.CLOB clob = (oracle.sql.CLOB) customer.getDescription();
11java.io.Writer pw = clob.getCharacterOutStream();
12pw.write(longText);//longText是一个长度超过255的字符串
13pw.close();
14tx.commit();
15session.close();

* 一个java类型对应多个Hibernate映射类型的场合。例如，如果持久化类的属性为java.util.Date类型，对应的Hibernate映射类型可以是date,time
或timestamp。此时必须根据对应的数据库表的字段的SQL类型，来确定Hibernate映射类型。如果字段为Date类型，则hibernate映射为datge，如果为TIME则为time，如果为TIMESTAMP则为timestamp。

2.客户化映射类型
（很麻烦的一个东西，稍微看了看，日后需要再研究并总结）

Eric5231 2008-01-24 15:57 发表评论

第八章映射组成关系

Eric5231 — Wed, 23 Jan 2008 12:47:00 GMT

1. 建立域模型和关系数据模型有着不同的出发点：域模型是由程序代码组成的，通过细化持久化类的粒度来提高代码可重用性，简化编程；而关系数据模型是由关系数据组成的，在存在数据冗余的情况下，可以把粗粒度的表拆分成具有外键参照关系的几个细粒度表，此外在没有数据冗余的情况下应该尽可能减少表的数目，简化表之间的参照关系。
域模型中的聚集aggregation对象关系在关系数据模型中可以通过映射为组成关系来提高代码和数据库访问质量。比如说一个customer具有homeAddress和comAddress属性，从域模型出发，应该把homeAddress和comAddress抽取出来成为一个过程对象。而在关系数据模型中可以通过hibernate提供的组成关系进行映射。映射文件如下：

1<component name="homeAddress" class="com.homeAddress">
2  <parent name="customer"/>
3  <property name="street" type="String" column="HOME_STREET"/>
4  <property name="city" type="String" column="HOME_CITY"/>
5
6component>

这样进行映射后，并不需要为homeAddress和comAddress单独设置数据库表，应该把homeAddress和comAddress的属性都和customer表放在一起
而有一点要格外注意的是，域模型的组成对象homeAddress和comAddress对象除了具有一般的属性成员变量外，需要为hibernate提供一个parent属性，如下所示

1packge com;
2
3import java.io.Serializabel;
4
5public class HomeAddress implements Serializable{
6   private String street;
7   private String city;
8
9   private com.Customer customer;
10
11   public void setCustomer(Customer customer){}
12      public Customer getCustomer(){}

hibernate提供的这种组成关系映射允许嵌套使用

1<component>
2  <compoent>
3
4  componet>
5
6component>

2. 区分值value类型和实体Entity类型
Hibernate把持久化类的属性分为value和Entity类型。前者没有OID，不能被单独持久化，不能单独通过session加载，它的生命周期依赖于所属的持久化类的对象生命周期，组件类型就是一种类型；而后者有OID，可以被单独持久化。在通过Configuration类的addClass（）方法加载映射文件时，只需要加载与value类型对应的实体类型，而不需要单独加载组件类。当通过hibernate进行数据库操作的时候，hibernate会自动把组件类的属性转换为实体类的属性，从而和table的列对应起来

Eric5231 2008-01-23 20:47 发表评论

第六章映射对象标识符

Eric5231 — Mon, 21 Jan 2008 13:45:00 GMT

标识符生成器	描述	备注
increment	由hibernate通过计算max（ID）来获得标识符，并自动以递增的方式增长	只适用于单个hibernate应用进程访问同一个数据库场合，在集群环境下不推荐
identity	有底层数据库自动增长支持，因此必须是底层数据库支持的自动增长类型	long，int，short
sequence	根据底层数据库的序列来生成标识符	long，int，short
hilo	根据high/low算法来生成标识符	long，int，short
native	根据底层数据库对自动生成标识符的支持能力来选择identity，sequenece或hilo	long，int，short
uuid.hex	采用128位的UUID生成在网络环境下唯一的字符串标识符，单占空间比较多	long，int，short
assigned	由java程序负责生成标识符	long，int，short

Eric5231 2008-01-21 21:45 发表评论

第七章持久化对象

Eric5231 — Mon, 21 Jan 2008 13:25:00 GMT

1）与Java对象在JVM中的生命周期类似，Java对象在Hibernate的session中也有生命周期类似的状态。在Hibernate的session中，对象有3种状态：临时状态，持久化状态，游离状态。

        a. 临时状态（transient），刚new出来的对象，还没有被session持久化，不处于session的缓存中

        b.持久化状态（persistent），已经被持久化（在数据库中有相应的记录），并且存在于session的缓存中

        c. 游离状态（detached），已经被持久化（在数据库中可能存在也可能不存在相应的记录），不存在于session的缓存中

简单的用个例子描述一下：

1

2tx = session.beginTransaction();

3Customer c1 = new Customer("Tom",new HashSet());    //c1 处于临时状态

4session.save(c1);                                                                   //c1转换为持久化状态

5Long id = c1.getId();

6c1 = null;

7Customer c2 = (Customer)session.load(Customer.class,id);     //c2 处于持久化状态

8tx.commit();

9session.close();                                                                                //c1转换为游离状态

10c2 = null;                                                                                          //c2转换为游离状态

2）对象的状态转换

状态名称	状态特征	进入条件	备注
临时对象	1.不存在任何一个session； 2.在数据库没有相应的记录；	1. 通过new； 2.Session通过delete()把持久化对象和游离对象转化为临时对象
持久化对象	1.总是被一个Session对象关联； 2.在数据库有相应的记录； 3.session清理缓存的时候，会根据持久化对象的属性变化（其实根据快照），来同步更新数据库	1.session的save()把临时对象转化持久化对象； 2.session的load()或get()返回的对象； 3.session的find()返回的对象； 4.session的update(),saveOrUpdate()和lock()使游离对象转变为持久化对象； 5.当一个持久化对象关联一个临时对象，当允许级联保存的情况下，临时对象也转化为持久化对象；	1.避免多个session实例关联一个Java对象
游离对象	1.不被session关联； 2.游离对象是由持久化对象转化过来的，数据库中可能存在也可能不存在相应的记录；	1.session的close()，把缓存中的所有持久化对象都转变为游离对象； 2.session的evict()，把缓存中的一个持久化对象删除，使它变成游离状态；	1.游离对象和临时对象的区别在于数据库是否存在相应的记录

3)Session的缓存以及API

    1.Session：在Session接口的实现类SessionImpl中定义了一系列的Java集合，这些集合构成了Sessiond缓存

    2.API：

save()	1.在save一个临时对象之前，设置对象的主键ID，没效果； 2.在save一个对象之后，对象主键ID不能修改，否则抛异常； 3.如果主键ID是用nactive方式生成的，一旦调用session的save方法，hibernate会立即向数据库插入数据； 4.save用来持久化一个临时对象，若持久一个持久化对象，没效果，若持久一个游离对象，会重新插入数据；
update()	1.session清理缓存的时候，才会去执行update()产生的sql语句，因此即使程序多次修改对象属性，最后只会更新最后的修改； 2.通过update()使一个游离对象被一个session关联，即使没有修改对象属性，在清理缓存的时候也会执行update()产生sql语句（如果希望仅当修改对象属性才进行update，可在<class>元素的select-before-update设置为true）； 3.当update()方法关联一个游离对象，如果session中存在相同OID的持久化对象，会抛出异常； 4.当update()方法关联一个游离对象，如果数据库中不存在相应记录，会抛出异常；
saveOrUpdate()	1.如果传入的是临时对象，调用save(); 如果传入的是持久化对象，调用update();
load(), get()	1.两者都是根据OID从数据库中加载持久化对象，区别是：当数据库不存在与OID对应的记录，load()会抛出net.sf.hibernate.ObjectNotFoundException，而get()方法返回null；
delete()	1.对传入的是持久化对象，session就按照预先的sql语句删除一个记录；如果是一个游离态对象，会把它关联到session，在按照sql语句删除记录

    3.session的级联：因为对象是相互关联，因此在session存放的是一副相互关联的对象图。在对象-关联映射文件中，用于映射持久化类之间关联的元素，如<set>,<many-to-one>,<one-to-many>，都有一个cascade属性。casecade属性值如下：

属性值	描述
none	默认值，忽略关联对象
save-update	session对当前对象调用save(),update(),saveOrUpdate()，级联保存关联的临时对象，级联更新关联的游离对象
delete	级联删除所有关联的对象
all	包含save-update(),delelte()行为；当对当前对象执行evict()或lock()，级联执行关联的对象
delete-orphan	删除所有和当前对象解除关联关系的对象
all-delete-orphan	包含all和delete-orphan的行为

Eric5231 2008-01-21 21:25 发表评论

关于hibernate category

Eric5231 — Mon, 21 Jan 2008 12:03:00 GMT

‘只有沉得下去的人，才能浮起来’

很久之前因为课程项目的缘故，杂七杂八的学了一段时间hibernate，实操也不多，在pccw实习的那段期间一直虽然接触着hibernate，但是从来都是扮演着木头的角色，没有真正思考过用得对不对，如果不对，又应该怎么去改善或者提高

这段时间，闲着也闲着，回去pccw是不可能的了，人还是要有自己的原则的，破坏了自己的原则，你在别人心中的形象也会随之而毁的；干脆静下心来，在学习新东西之前，好好重新复习一些东西，好好把孙卫琴的《精通Hibernate》复习一遍

于是hibernate这个Category应运而生

Eric5231 2008-01-21 20:03 发表评论

BlogJava-Ericzhang5231-文章分类-Hibernate

（转）Spring事务传播机制解惑

（转）Spring事务传播机制解惑

Transaction always commits even if marked readOnly

利用ThreadLocal管理session

Spring的Hibernate事务管理

Hibernate的Load和get方法区别

第十三章 管理Hibernate的缓存

第十一章 Hibernate的检索方式

第九章 Hibernate的映射类型

第八章 映射组成关系

第六章 映射对象标识符

第七章 持久化对象

关于hibernate category

第十三章管理Hibernate的缓存

第八章映射组成关系

第六章映射对象标识符

第七章持久化对象