引子
今天下班后，以前同事小胖问我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.
明细配置：
花了一个小时整理这混乱的东西，小胖快来看吧。哈哈。思路混乱，大家能看就看，想拍就拍。只是为我和小胖两人理解。大家有想法，欢迎一起扯淡。
- 大小: 42.1 KB
- 大小: 29.9 KB
- 大小: 25.5 KB
- 大小: 59.2 KB
分享到：
相关推荐
spring事务管理注解jar,spring-tx-3.2.4.RELEASE.jar,导入项目即可
Spring3引入了基于注解的事务管理，极大地简化了事务配置，使得开发者可以在方法级别声明事务边界，这就是`@Transactional`注解的用处。本文将深入探讨这个注解以及如何在Spring3中有效地使用它。 `@Transactional`...
@Transactional实现原理.txt
Spring支持四种标准的JDBC隔离级别：READ_UNCOMMITTED、READ_COMMITTED、REPEATABLE_READ和SERIALIZABLE。开发者可以通过`@Transactional`注解的`isolation`属性来设置。 Spring `@Transactional`的实现中，持久化...
通过 @Transactional 注解，可以指定事务的传播行为、隔离级别、读写控制等属性。 首先，@Transactional 注解支持 9 个属性的设置，常用的三个属性是 readOnly、propagation 和 isolation。其中，readOnly 用于读写...
SpringBoot 中事务管理 @Transactional 的注意事项与使用场景 在本篇文章中，我们将详细讲解 SpringBoot 中事务管理 @Transactional 的注意事项与使用场景，以帮助开发者更好地理解和使用 @Transactional 注解。 ...
`@Transactional`是Spring提供的一个注解，用于在方法级别或类级别定义事务属性，如事务的传播行为、隔离级别、读写模式以及超时设置。当一个方法被标记为`@Transactional`时，Spring会自动管理事务的开始、提交或...
在Java编程中，`@Transactional`注解是Spring框架提供的一种事务管理机制，它使得开发者能够在方法级别方便地声明事务边界。然而，在某些特定情况下，`@Transactional`可能会失效，导致事务无法正常工作。以下是一些...
typeorm-transactional-cls-hooked Transactional方法装饰器，使用处理和传播不同存储库和服务方法之间的事务。 受到注释和启发 见 安装 npm install --save typeorm-transactional-cls-hooked # # Needed ...
常用注解：@Controller @RestController(Controller+ResponseBody) @Service @Transactional @Mapper @AutoWired @RequestMapping--路由 @RequestParam--参数绑定（不同名参数或Map<Object,String>） @...
`@Transactional`可以设置不同的属性，如`propagation`（传播行为）、`isolation`（隔离级别）、`rollbackFor`（触发回滚的异常类型）等。下面是一个声明式事务的例子： ```java @Service public class UserService...
Spring @Transactional 注解失效解决方案 在 Spring 框架中，@Transactional 注解是用于管理事务的关键工具之一。但是，在实际开发中，我们经常会遇到 @Transactional 注解失效的问题。本篇文章将详细介绍 @...
Java注解@Transactional事务类内调用不生效问题及解决办法 Java注解@Transactional是Java中的一种注解，主要用于标记事务边界。然而，在某些情况下，@Transactional注解可能不会生效，例如在同一个类中的方法调用...
"Spring @Transactional 无效的解决方案" Spring框架中的@Transactional注解是用来实现事务管理的，但是有时候我们可能会遇到@Transactional注解无效的情况。在这篇文章中，我们将 introducethe 解决方案，并通过...
首先，`@Transactional`是Spring提供的一个编程式事务管理方式，它允许我们在方法上声明事务属性，如传播行为、隔离级别、读写模式以及是否回滚。例如： ```java @Service public class UserService { @...
浅谈Spring中@Transactional事务回滚及示例 @Transactional是Spring Framework中的一种事务管理机制，用于管理数据库事务。它可以使得数据库操作更加安全和可靠。本文将详细介绍@Transactional的使用场景、checked...
在Spring框架中，`@Transactional` 和 `@Async` 是两个非常重要的注解，它们分别用于声明事务管理和异步执行。然而，当这两个注解同时出现在一个方法上时，可能会引发一些复杂的问题，特别是在存在循环依赖的情况下...
`@Transactional`注解允许指定这些属性，如`propagation`（传播行为）、`isolation`（隔离级别）、`readOnly`（只读事务）等。 总的来说，Spring的`@Transactional`注解为开发者提供了方便且强大的声明式事务管理...