@Transactional-隔离级别-二级缓存的扯谈

引子

今天下班后，以前同事小胖问我Spring  Service类中的注解@Transactional readOnly=true的作用。做为他眼中的高人，我自然要装下A-C。居然想都没有想就说是注解事务控制，然后给他扯了一通数据库的隔离级别，什么read uncommit之类的,说readOnly是隔离级别最低的，在spring查询方法里用，性能最高。
ps:之前的项目多数基于xml，亲自用annotation的机会很少，都是小弟们在实战。

示例：

@Component("channelService")
@Transactional(readOnly = true)
public class ChannelServiceImpl implements IChannelService {
    @Resource(name = "productService")
    private IProductService productService;

    /**
     * 根据频道名字查询频道。没有就返回NULL。
     *
     * @param name 频道名称不能为空。
     * @return （假设频道名称是加了唯一约束的，否则可能结果不止一条导致异常）
     */
    @MethodCache(expire = 3600)
    @Transactional(readOnly = true)
    public ChannelVO getChannelByName(String name) {
        if (name == null || "".equals(name.trim())) {
            throw new IllegalArgumentException("name=" + name);
        }
        ShopChannels channel = (ShopChannels) channelDao.createCriteria()
                .add(Restrictions.eq("name", name))
                .uniqueResult();
        if (channel == null) {
            return new ChannelVO();
        }
        ChannelVO vo = new ChannelVO();
        DozerMapper.getInstance().map(channel, vo);
        //增加频道对应商品分类id 只取第一个分类
        Set<ProductClass> listCates = channel.getProductClasses();
        if (listCates != null && !listCates.isEmpty()) {
            vo.setProductClass("" + listCates.iterator().next().getSid());
        }
        List<Integer> list = new ArrayList<Integer>();
        Iterator<ProductClass> iterator = listCates.iterator();
        while (iterator.hasNext()) {
            ProductClass productClass = iterator.next();
            list.add(productClass.getSid());
        }
        vo.setAllProductClass(list);
        return vo;
}
}

数据库隔离相关内容

在一个应用中，依据事务的隔离级别将会有三种情况发生。
　　◆脏读（dirty read）：当一个事务读取另一个事务尚未提交的修改时，产生脏读。
　　◆ 不可重复读（non-repeatable read）：同一查询在同一事务中多次进行，由于其他提交事务所做的修改或删除，每次返回不同的结果集，此时发生非重复读。：
　　◆ 幻像读（phantom read）：同一查询在同一事务中多次进行，由于其他提交事务所做的插入操作，每次返回不同的结果集，此时发生幻像读。

1.Read Committed:
假设A事务对正在读取数据Data放置了共享锁，那么Data不能被其它事务改写，所以当B事务对Data进行读取时总和A读取的Data数据是一致的，所以避免了脏读。由于在A没有提交之前可以对Data进行改写，那么B读取到的某个值可能会在其读取后被A更改从而导致了该值不能被重复取得；或者当B再次用相同的where字句时得到了和前一次不一样数据的结果集，也就是幻像数据。

2.Read Uncommitted：
假设A事务即不发布共享锁，也不接受独占锁，那么并发的B或者其它事务可以改写A事务读取的数据，那么并发的C事务读取到的数据的状态和A的或者B的数据都可能不一致，那么。脏读、不可重复读、幻象数据都可能存在。

3.Repeatable Read：
（注意MSDN原文中的第一句话：在查询中使用的所有数据上放置锁，所以不存在脏读的情况）。
假设A事务对读取的所有数据Data放置了锁，以阻止其它事务对Data的更改，在A没有提交之前，新的并发事务读取到的数据如果存在于Data中，那么该数据的状态和A事务中的数据是一致的，从而避免了不可重复的读取。但在A事务没有结束之前，B事务可以插入新记录到Data所在的表中，那么其它事务再次用相同的where字句查询时，得到的结果数可能上一次的不一致，也就是幻像数据。

4.Serializable：
在数据表上放置了排他锁，以防止在事务完成之前由其他用户更新行或向数据集中插入行，这是最严格的锁。它防止了脏读、不可重复读取和幻象数据。

以下是对照表：




一般的应用作隔离级别时，往往采用(2),(3)两种，(1),(4)两种前者轻后者重，但是Hibernate为了提高performance和scalability，在数据库一层中采用的是(2)的隔离级别，然后在程序中进行控制，从而实现了(3)的隔离级别，因此提高了企业应用的事务处理效率。当然Hibernate对于数据库一层的隔离级别也可以显示指定。Hibernate在程序中的控制方法有:version number, timestamp,对于遗留database也有optimistic-lock，而version number有时不能解决特殊的事务并发引起来的(3)问题，那么就需要针对特殊情况进行细粒度的事务控制，可以看一下LOCKMODE。

回家反思缓存策略

回家一想，不对，应该不完全是隔离级别的东西，自已可能肯定搞错了，于是赶紧翻看hibernate3.3 reference.果然没说对。应该是二级缓存的策略问题。但不知为什么reference中没有讲到query cache annotation的东西，只是一页带过。提高性能中二级缓存策略倒是讲了不少。
备忘:

Chapter 19. Improving performance
19.2. The Second Level Cache
19.2.1. Cache mappings
The <cache> element of a class or collection mapping has the following form:

<cache 
    usage="transactional|read-write|nonstrict-read-write|read-only"  
    region="RegionName"                                              
    include="all|non-lazy"                                           
/>

usage (required) specifies the caching strategy: transactional, read-write, nonstrict-
read-write or read-only
region (optional: defaults to the class or collection role name): specifies the name of the
second level cache region
include (optional: defaults to all) non-lazy: specifies that properties of the entity mapped
with lazy="true" cannot be cached when attribute-level lazy fetching is enabled
Alternatively, you  can  specify  <class-cache> and  <collection-cache>  elements  in
hibernate.cfg.xml.
The usage attribute specifies a cache concurrency strategy.

直接简要的看各种策略说明：

Strategy: read only
If your application needs to read, but not modify, instances of a persistent class, a read-only
cache can be used. This is the simplest and optimal performing strategy. It is even safe for use
in a cluster.
如果应用只需要查询，不需要修改，那么read-only缓存将使用，这是最简单、最理想的性能策略,它在集群环境下也是安全的。

Strategy: read/write
If  the  application  needs  to  update  data, a  read-write  cache  might  be  appropriate.This  cache  strategy  should  never  be  used  if  serializable  transaction  isolation  level  is required. 
如果应用需要修改，read-write cache是最合适的。这个cache策略永远不会使用，如果数据库事务隔离级别是可序列化serializable的。这里看和隔离级别又有点关系。

Strategy: nonstrict  read/write
If the application only occasionally needs to update data (i.e. if it is extremely unlikely that two
transactions would try to update the same item simultaneously), and strict transaction isolation
is not required, a nonstrict-read-write cache might be appropriate. If the cache is used in a
JTA environment, you must specify hibernate.transaction.manager_lookup_class. In other
environments, you should ensure that the transaction is completed when Session.close() or
Session.disconnect() is called.
如果应用仅仅偶尔的修改数据，并不需要严格的数据库隔离级别。Nonstrict-read-write 缓存是最合适的。

Strategy: transactional
The transactional cache strategy provides support for fully  transactional cache providers such
as JBoss TreeCache. Such a cache can only be used in a JTA environment and you must specify
hibernate.transaction.manager_lookup_class.
The transactional cache strategy提供完全的事务缓存机制，例如JBoss TreeCache.这样的缓存只能用在JTA环境中，你也必需指定相关类。

Important
None of the cache providers support all of the cache concurrency strategies.
The following table shows which providers are compatible with which concurrency strategies.




回归正题@Transactional

再想想，还是不对，hibernate中并没有提到最开始annotation的东西，于是继续纠结Spring3.0 Reference Documentation。

Using @Transactional
In addition to the XML-based declarative approach to transaction configuration, you can use an
annotation-based approach. Declaring transaction semantics directly in the Java source code puts the declarations much closer to the affected code. There is not much danger of undue coupling, because code that is meant to be used transactionally is almost always deployed that way anyway.
annotation事务控制，代替xml的。其它废话少翻。
You can place the @Transactional annotation before an interface definition, a method on an Interface, a class definition, or a public method on a class. However, the mere presence of the
@Transactional annotation is not enough to activate the transactional behavior. The
@Transactional annotation is simply metadata that can be consumed by some runtime infrastructure that is @Transactional-aware and that can use the metadata to configure the appropriate beans with transactional behavior. In the preceding example, the <tx:annotation-driven/> element switches
onthetransactionalbehavior.

//文档例子：
@Transactional(readOnly = true)
public class DefaultFooService implements FooService {
public Foo getFoo(String fooName) {
// do something
}
// these settings have precedence for this method
@Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
public void updateFoo(Foo foo) {
// do something
}
}

@Transactional  settings
The @Transactional annotation is metadata that specifies that an interface, class, or method must have transactional semantics; for example, “start a brand new read-only transaction when this method is invoked。
@Transactional 注解是规定接口，类或者方法必需应用事务的元数据语法。

看看spring默认的设置：

//默认传播机制：PROPAGATION_REQUIRED
* Propagation setting is PROPAGATION_REQUIRED.
//默认隔离级别：ISOLATION_DEFAULT
* Isolation level is ISOLATION_DEFAULT.
//默认事务是read/write.到此知道查询配readOnly的作用。
* Transaction is read/write.
//事务默认超时时间取决于事务系统，也有可能没有，如果事务系统不支持。
* Transaction timeout defaults to the default timeout of the underlying transaction system, or to none if time outs are not supported.
//任何的RuntimeExcetipn将触发回滚，任何的checkedException不触发回滚。
* Any RuntimeException triggers rollback,and any checkedException does not.

明细配置：








花了一个小时整理这混乱的东西，小胖快来看吧。哈哈。思路混乱，大家能看就看，想拍就拍。只是为我和小胖两人理解。大家有想法，欢迎一起扯淡。