转:http://blog.csdn.net/seng3018/article/details/6690587
今天下班后，以前同事小胖问我Spring Service类中的注解@Transactional readOnly=true的作用。做为他眼中的高人，我自然要装下A-C。居然想都没有想就说是注解事务控制，然后给他扯了一通数据库的隔离级别，什么read uncommit之类的,说readOnly是隔离级别最低的，在spring查询方法里用，性能最高。
ps:之前的项目多数基于xml，亲自用annotation的机会很少，都是小弟们在实战。
示例：
Java代码
@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:
Java代码
<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.
Java代码
//文档例子：
@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默认的设置：
Java代码
//默认传播机制：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.
明细配置：
结论1:readOnly=true表明所注解的方法或类只是读取数据。
readOnly=false表明所注解的方法或类是增加，删除，修改数据。
从他的描述Read/write vs. read-only transaction，就能猜出一二来。
如果设置为true，spring会对其优化，可以用来提高性能。他提供了不一样的connection
结论2: 摘自http://geng2483759.iteye.com/blog/319768
你应该仔细看一下Spring的文档，在事务那一章有明确的解释：
“只读事务”并不是一个强制选项，它只是一个“暗示”，提示数据库驱动程序和数据库系统，这个事务并不包含更改数据的操作，那么JDBC驱动程序和数据库就有可能根据这种情况对该事务进行一些特定的优化，比方说不安排相应的数据库锁，以减轻事务对数据库的压力，毕竟事务也是要消耗数据库的资源的。
但是你非要在“只读事务”里面修改数据，也并非不可以，只不过对于数据一致性的保护不像“读写事务”那样保险而已。
因此，“只读事务”仅仅是一个性能优化的推荐配置而已，并非强制你要这样做不可。
1. 和spring文档没有任何关系，spring事务仅仅是一层封装，最后都要调用底层驱动的setReadonly方法来开启。
2.在大多数数据库系统下，只读事务里面是不可以修改数据，并且，在同一个事务里面同一个sql读出来的同一条记录是不会变化的，这是我们开启readonly最重要的原因：我们需要能够可重复读。
3. 在一个系统中，为了保证在同一个事务中读取数据的一致性，对一系列读操作开启readonly是很重要的做法，并不仅仅是性能优化的推荐配置。
4. 最重要的是，spring的DataSourceTransactionManager确实不支持readonly，我开头的连接中已经给出了原因。
1.readonly语义不是所有的数据库驱动都支持的。
2.在spring+hibernate的条件下，readonly有一些优化
http://www.iteye.com/topic/95124说的没错， 有的数据库驱动是不支持readonly的。但在oracle下绝对支持，上面也已经验证过了。
顺便回答下你帖子里一个问题： 使用jdbc不但没有优化，压根jdbc的这个DataSourceTransactionManager就不支持readonly。因为它源代码里面没有一处调用con.setReadOnly(true)之类的方法。
而HibernateTransactionManager中正如你所说的会有这么一段：
