语源科技BlogJava-wmcoo

Spring中对hibernate映射文件的配置技巧

岁月神偷 — Wed, 20 Oct 2010 15:38:00 GMT

mappingLocations、mappingDirectoryLocations与mappingJarLocations 区别

由于spring对hibernate配置文件hibernate.cfg.xml的集成相当好，
所以，在项目中我一直使用spring的org.springframework.orm.hibernate.LocalSessionFactoryBean来取代hibernate.cfg.xml文件的功能
LocalSessionFactoryBean有好几个属性用来查找hibernate映射文件：mappingResources、mappingLocations、mappingDirectoryLocations与mappingJarLocations
他们的区别：
mappingResources：指定classpath下具体映射文件名

petclinic.hbm.xml

mappingLocations：可以指定任何文件路径，并且可以指定前缀：classpath、file等

/WEB-INF/petclinic.hbm.xml

classpath:/com/company/domain/petclinic.hbm.xml

也可以用通配符指定，'*'指定一个文件(路径)名，'**'指定多个文件(路径)名，例如：

classpath:/com/company/domain/**/maps/*.hbm.xml

上面的配置是在com/company/domain包下任何maps路径下的hbm.xml文件都被加载为映射文件

mappingDirectoryLocations：指定映射的文件路径
mappingJarLocations：指定加载的映射文件在jar文件中

岁月神偷 2010-10-20 23:38 发表评论

数据库三范式，轻松理解

岁月神偷 — Wed, 13 Oct 2010 01:45:00 GMT

官方定义：第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。
我的理解：第一范式这个不用說了，只要是关系数据库都满足第一范式

官方定义：第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖
我的理解：在第二范式中组合主键（AB）【注明：也叫做复合主键】里面的A或者B 与其他字段不能存在组合重复，为解决这个问题，通常的做法是咱们不用组合主键，添加一个ID，做为单一主键即可满足第二范式。如果不想添加ID，请满足组合主键（AB）里面的A或者B 与其他字段不能存在组合重复。
如:不满足第二范式,复合主键中的A与字段C组合重复
+------------+-----------+-------------------+
pk pk row
+------------+-----------+-------------------+
A B C
+------------+-----------+-------------------+
A D C
+------------+-----------+-------------------+
A E C
+------------+-----------+-------------------+

改为这样满足第二范式(但是不满足第三范式,字段A与字段C是组合重复):
+---------+------------+-----------+-------------------+
pk row row row
+---------+------------+-----------+-------------------+
1 A B C
+---------+------------+-----------+-------------------+
2 A D C
+---------+------------+-----------+-------------------+
3 A E C
+---------+------------+-----------+-------------------+

官方定义：第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。
我的理解：在第三范式中字段与字段之间不能存在组合重复
如:不满足第三范式,字段A与字段C组合重复
+---------+------------+-----------+-------------------+---------------+
pk row row row row
+---------+------------+-----------+-------------------+---------------+
1 A B C F
+---------+------------+-----------+-------------------+---------------+
2 A D C G
+---------+------------+-----------+-------------------+---------------+
3 A E C K
+---------+------------+-----------+-------------------+---------------+

改为这样满足第三范式:
表1
+---------+------------+-----------+
pk row row
+---------+------------+-----------+
1 A B
+---------+------------+-----------+
2 A D
+---------+------------+-----------+
3 A E
+---------+------------+-----------+
和表2
+---------+-------------------+------------+
pk row row
+---------+-------------------+------------+
1 C F
+---------+-------------------+------------+
2 C G
+---------+-------------------+------------+
3 C K
+---------+-------------------+------------+

原则:当出现字段与字段的组合重复,如上的A和C的组合重复,首先要考虑的就是把他们拆分为2个表,具体是C拆到表1, 还是A拆到表1,看情况而定.

关键要理解定义这种范式标准的主要目的是为了减少数据冗余，数据冗余产生的本质就是在一个表中存在字段与字段之间的一对多，或者多对多关系。解决这个几对几的关系问题，就能轻易实现满足第三范式的数据库设计。

总结:
1NF:不允许用一个字段来表示多个字段的属性.

2NF:不允许复合主键与字段之间的组合重复.

3NF:不允许字段与字段之间的组合重复.

岁月神偷 2010-10-13 09:45 发表评论

Java操作符的优先级和结合性

岁月神偷 — Tue, 12 Oct 2010 12:21:00 GMT

	优先级	结合性
1	[ ] . ( ) (函数呼叫)	从左到右
2	! ~ ++ -- +(单操作数) –(单操作数) ( ) (类型转化) new	从右到左
3	* / %	从左到右
4	+ -	从左到右
5	<< >> >>>	从左到右
6	< <= > >= instanceof	从左到右
7	== !=	从左到右
8	&	从左到右
9	^	从左到右
10	\|	从左到右
11	&&	从左到右
12	\|\|	从左到右
13	? :	从右到左
14	= += -= *= /= %= ^= <<= >>= >>>=	从右到左

岁月神偷 2010-10-12 20:21 发表评论

软件工程之开发流程

岁月神偷 — Mon, 11 Oct 2010 02:06:00 GMT

　　可行性分析

　　这个一般都是做战略的专家来做的，他们更加有市场的前瞻性，俗话说就是看的更远一些，搞市场分析、调研，看看我们的想法到底是否可行，可行性有多大，可能会遇到的问题，我们的优势在哪里，可以利用的资源有哪些，需要引进那些资源，有多少对手，他们都进行到了什么程度等等。

　　这个阶段的文档成果是：可行性分析报告等

　　需求分析

　　这个已经开始具体操作，经过可行性分析，我们有机会，可以进入这个领域。这时候，需要领域专家参与进来，架构师也要参与进来，还有就是需求分析的专业人士，和最少一名文档员，用来记录开发讨论的结果并形成文档。

　　工作就是分解项目的需求，到底要做些什么，要实现什么功能，就是功能的范围和功能的细节，主要还是业务方面的梳理。

　　这个阶段的文档成果是：需求分析说明书等

　　概要设计

　　经过前面的需求分析，形成了需求分析说明书。这个阶段应该是业务建模，形成业务用例，进一步形成业务用例。这个阶段是分解需求，可以使用PD(Power Designer)、 Rational等工具来辅助一下。

　　这个阶段的文档成果是：概要设计说明书、业务用例文档等

　　详细设计

　　有了概要设计，有了模型，可以定义出数据库模型，甚至是可以定义数据库的字段，然后可以让高级程序员来辅助架构师进行架构设计，普通程序员先写实现的技术用例。或者让他们先看看业务用例，熟悉一下业务流程和项目的目标。

　　这个阶段的文档成果是：概要设计说明书、技术用例文档等

　　具体开发

　　这个阶段就是具体的代码编写了，考验程序员的基本功的时候到了。

关于开发的分工的话，我趋向于分层来分工，这样有以下几个好处：

不用每个人从数据访问写到界面表现，可以集中精力，精益求精，便于后期优化
中间层可拔插，可替换，可以优化，增加可扩展性

岁月神偷 2010-10-11 10:06 发表评论

Hibernate 的session.flush()机制

岁月神偷 — Mon, 11 Oct 2010 01:39:00 GMT

session.flush()同步当前的Session缓存中的SQL到数据库,当设置setAutoCommit(false)数据库实体表并不会改变,因为同步的SQL没有提交.

在下面的情况下，Hibernate会调用Session.flush()以清理缓存：
1)事务提交时，如果flush模式不为FlushMode.NEVER,commit()将调用flush().
2)在某些查询语句之前（此查询语句之前的语句已经改变了数据库状态，所以需要调用flush（）以同步数据库是查出来的数据是经过更改的）。

在调用Session.flush()时，涉及的SQL语句会按照下面的顺序执行。
（1）         所有的实体经行插入的语句，其顺序按照对象执行Session.save()的时间顺序。
（2）         所有对实体经行更新的语句
（3）         所有经行集合的删除语句
（4）         所有对集合元素进行删除，更新或者插入的语句
（5）         所有经行集合插入的语句
（6）         所有对实体经行删除的语句，其顺序按照对象执行Session.delete()的时间顺序。
（7）         有一个例外是，如果对象使用native方式生成的ID（持久化标识），则他们一执行save就会被插入。

通过设置session.setFlushMode(),可以精确控制Hibernate的FlushMode.
(1)                FlushMode.AUTO:Hibernate判断对象属性有没有改变，如果被更改成为脏数据，则在一个查询语句钱将更新此改动以保证数据库的同步。这也是
Hibernate的默认清理模式。
(2) FlushMode.COMMIT:在事务结束之前清理session的缓存。这样有可能导致查出脏数据
(3)                FlushMode.NEVER：除非强制调用Session.flush(),否则永远不清理Session。想当于将数据库设置为一个只读的数据库。
(4)                FlushMode.ALWAYS：在每一个查询数据之前都调用Session.flush()。很显然这种效率很低。只用当使用触发器，或把Hibernate和JDBC混合使用，直接调用Session.flush()才是有意义的。

岁月神偷 2010-10-11 09:39 发表评论

Hibernate二级缓存

岁月神偷 — Mon, 11 Oct 2010 01:31:00 GMT

hibernate的session提供了一级缓存，每个session，对同一个id进行两次load，不会发送两条sql给数据库，但是session关闭的时候，一级缓存就失效了。

二级缓存是SessionFactory级别的全局缓存，它底下可以使用不同的缓存类库，比如ehcache、oscache等，需要设置hibernate.cache.provider_class，我们这里用ehcache，在2.1中就是
hibernate.cache.provider_class=net.sf.hibernate.cache.EhCacheProvider
如果使用查询缓存，加上
hibernate.cache.use_query_cache=true

缓存可以简单的看成一个Map，通过key在缓存里面找value。

Class的缓存
对于一条记录，也就是一个PO来说，是根据ID来找的，缓存的key就是ID，value是POJO。无论list，load还是iterate，只要读出一个对象，都会填充缓存。但是list不会使用缓存，而iterate会先取数据库select id出来，然后一个id一个id的load，如果在缓存里面有，就从缓存取，没有的话就去数据库load。假设是读写缓存，需要设置：

如果你使用的二级缓存实现是ehcache的话，需要配置ehcache.xml

其中eternal表示缓存是不是永远不超时，timeToLiveSeconds是缓存中每个元素（这里也就是一个POJO）的超时时间，如果eternal="false"，超过指定的时间，这个元素就被移走了。timeToIdleSeconds是发呆时间，是可选的。当往缓存里面put的元素超过500个时，如果overflowToDisk="true"，就会把缓存中的部分数据保存在硬盘上的临时文件里面。
每个需要缓存的class都要这样配置。如果你没有配置，hibernate会在启动的时候警告你，然后使用defaultCache的配置，这样多个class会共享一个配置。
当某个ID通过hibernate修改时，hibernate会知道，于是移除缓存。
这样大家可能会想，同样的查询条件，第一次先list，第二次再iterate，就可以使用到缓存了。实际上这是很难的，因为你无法判断什么时候是第一次，而且每次查询的条件通常是不一样的，假如数据库里面有100条记录，id从1到100，第一次list的时候出了前50个id，第二次iterate的时候却查询到30至70号id，那么30-50是从缓存里面取的，51到70是从数据库取的，共发送1+20条sql。所以我一直认为iterate没有什么用，总是会有1+N的问题。
（题外话：有说法说大型查询用list会把整个结果集装入内存，很慢，而iterate只select id比较好，但是大型查询总是要分页查的，谁也不会真的把整个结果集装进来，假如一页20条的话，iterate共需要执行21条语句，list虽然选择若干字段，比iterate第一条select id语句慢一些，但只有一条语句，不装入整个结果集hibernate还会根据数据库方言做优化，比如使用mysql的limit，整体看来应该还是list快。）
如果想要对list或者iterate查询的结果缓存，就要用到查询缓存了

查询缓存
首先需要配置hibernate.cache.use_query_cache=true
如果用ehcache，配置ehcache.xml，注意hibernate3.0以后不是net.sf的包名了

maxElementsInMemory="50" eternal="false" timeToIdleSeconds="3600"
timeToLiveSeconds="7200" overflowToDisk="true"/>

maxElementsInMemory="5000" eternal="true" overflowToDisk="true"/>
然后
query.setCacheable(true);//激活查询缓存
query.setCacheRegion("myCacheRegion");//指定要使用的cacheRegion，可选
第二行指定要使用的cacheRegion是myCacheRegion，即你可以给每个查询缓存做一个单独的配置，使用setCacheRegion来做这个指定，需要在ehcache.xml里面配置它：

如果省略第二行，不设置cacheRegion的话，那么会使用上面提到的标准查询缓存的配置，也就是net.sf.hibernate.cache.StandardQueryCache

对于查询缓存来说，缓存的key是根据hql生成的sql，再加上参数，分页等信息（可以通过日志输出看到，不过它的输出不是很可读，最好改一下它的代码）。
比如hql：
from Cat c where c.name like ?
生成大致如下的sql：
select * from cat c where c.name like ?
参数是"tiger%"，那么查询缓存的key*大约*是这样的字符串（我是凭记忆写的，并不精确，不过看了也该明白了）：
select * from cat c where c.name like ? , parameter:tiger%
这样，保证了同样的查询、同样的参数等条件下具有一样的key。
现在说说缓存的value，如果是list方式的话，value在这里并不是整个结果集，而是查询出来的这一串ID。也就是说，不管是list方法还是iterate方法，第一次查询的时候，它们的查询方式很它们平时的方式是一样的，list执行一条sql，iterate执行1+N条，多出来的行为是它们填充了缓存。但是到同样条件第二次查询的时候，就都和iterate的行为一样了，根据缓存的key去缓存里面查到了value，value是一串id，然后在到class的缓存里面去一个一个的load出来。这样做是为了节约内存。
可以看出来，查询缓存需要打开相关类的class缓存。list和iterate方法第一次执行的时候，都是既填充查询缓存又填充class缓存的。
这里还有一个很容易被忽视的重要问题，即打开查询缓存以后，即使是list方法也可能遇到1+N的问题！相同条件第一次list的时候，因为查询缓存中找不到，不管class缓存是否存在数据，总是发送一条sql语句到数据库获取全部数据，然后填充查询缓存和class缓存。但是第二次执行的时候，问题就来了，如果你的class缓存的超时时间比较短，现在class缓存都超时了，但是查询缓存还在，那么list方法在获取id串以后，将会一个一个去数据库load！因此，class缓存的超时时间一定不能短于查询缓存设置的超时时间！如果还设置了发呆时间的话，保证class缓存的发呆时间也大于查询的缓存的生存时间。这里还有其他情况，比如class缓存被程序强制evict了，这种情况就请自己注意了。

另外，如果hql查询包含select字句，那么查询缓存里面的value就是整个结果集了。

当hibernate更新数据库的时候，它怎么知道更新哪些查询缓存呢？
hibernate在一个地方维护每个表的最后更新时间，其实也就是放在上面net.sf.hibernate.cache.UpdateTimestampsCache所指定的缓存配置里面。
当通过hibernate更新的时候，hibernate会知道这次更新影响了哪些表。然后它更新这些表的最后更新时间。每个缓存都有一个生成时间和这个缓存所查询的表，当hibernate查询一个缓存是否存在的时候，如果缓存存在，它还要取出缓存的生成时间和这个缓存所查询的表，然后去查找这些表的最后更新时间，如果有一个表在生成时间后更新过了，那么这个缓存是无效的。
可以看出，只要更新过一个表，那么凡是涉及到这个表的查询缓存就失效了，因此查询缓存的命中率可能会比较低。

Collection缓存
需要在hbm的collection里面设置

假如class是Cat，collection叫children，那么ehcache里面配置

maxElementsInMemory="20" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="7200"
overflowToDisk="true" />
Collection的缓存和前面查询缓存的list一样，也是只保持一串id，但它不会因为这个表更新过就失效，一个collection缓存仅在这个collection里面的元素有增删时才失效。
这样有一个问题，如果你的collection是根据某个字段排序的，当其中一个元素更新了该字段时，导致顺序改变时，collection缓存里面的顺序没有做更新。

缓存策略
只读缓存（read-only）：没有什么好说的
读/写缓存（read-write）:程序可能要的更新数据
不严格的读/写缓存（nonstrict-read-write）：需要更新数据，但是两个事务更新同一条记录的可能性很小，性能比读写缓存好
事务缓存（transactional）：缓存支持事务，发生异常的时候，缓存也能够回滚，只支持jta环境，这个我没有怎么研究过

读写缓存和不严格读写缓存在实现上的区别在于，读写缓存更新缓存的时候会把缓存里面的数据换成一个锁，其他事务如果去取相应的缓存数据，发现被锁住了，然后就直接取数据库查询。
在hibernate2.1的ehcache实现中，如果锁住部分缓存的事务发生了异常，那么缓存会一直被锁住，直到60秒后超时。
不严格读写缓存不锁定缓存中的数据。

使用二级缓存的前置条件
你的hibernate程序对数据库有独占的写访问权，其他的进程更新了数据库，hibernate是不可能知道的。你操作数据库必需直接通过hibernate，如果你调用存储过程，或者自己使用jdbc更新数据库，hibernate也是不知道的。hibernate3.0的大批量更新和删除是不更新二级缓存的，但是据说3.1已经解决了这个问题。
这个限制相当的棘手，有时候hibernate做批量更新、删除很慢，但是你却不能自己写jdbc来优化，很郁闷吧。
SessionFactory也提供了移除缓存的方法，你一定要自己写一些JDBC的话，可以调用这些方法移除缓存，这些方法是：
void evict(Class persistentClass)
Evict all entries from the second-level cache.
void evict(Class persistentClass, Serializable id)
Evict an entry from the second-level cache.
void evictCollection(String roleName)
Evict all entries from the second-level cache.
void evictCollection(String roleName, Serializable id)
Evict an entry from the second-level cache.
void evictQueries()
Evict any query result sets cached in the default query cache region.
void evictQueries(String cacheRegion)
Evict any query result sets cached in the named query cache region.
不过我不建议这样做，因为这样很难维护。比如你现在用JDBC批量更新了某个表，有3个查询缓存会用到这个表，用evictQueries(String cacheRegion)移除了3个查询缓存，然后用evict(Class persistentClass)移除了class缓存，看上去好像完整了。不过哪天你添加了一个相关查询缓存，可能会忘记更新这里的移除代码。如果你的jdbc代码到处都是，在你添加一个查询缓存的时候，还知道其他什么地方也要做相应的改动吗？

----------------------------------------------------

总结：
不要想当然的以为缓存一定能提高性能，仅仅在你能够驾驭它并且条件合适的情况下才是这样的。hibernate的二级缓存限制还是比较多的，不方便用jdbc可能会大大的降低更新性能。在不了解原理的情况下乱用，可能会有1+N的问题。不当的使用还可能导致读出脏数据。
如果受不了hibernate的诸多限制，那么还是自己在应用程序的层面上做缓存吧。
在越高的层面上做缓存，效果就会越好。就好像尽管磁盘有缓存，数据库还是要实现自己的缓存，尽管数据库有缓存，咱们的应用程序还是要做缓存。因为底层的缓存它并不知道高层要用这些数据干什么，只能做的比较通用，而高层可以有针对性的实现缓存，所以在更高的级别上做缓存，效果也要好些吧。

岁月神偷 2010-10-11 09:31 发表评论

Java类获取spring 容器的bean

岁月神偷 — Sat, 09 Oct 2010 02:18:00 GMT

常用的5种获取spring 中bean的方式总结：

方法一：在初始化时保存ApplicationContext对象
代码：
ApplicationContext ac = new FileSystemXmlApplicationContext("applicationContext.xml");
ac.getBean("beanId");
说明：这种方式适用于采用Spring框架的独立应用程序，需要程序通过配置文件手工初始化Spring的情况。

方法二：通过Spring提供的工具类获取ApplicationContext对象
代码：
import org.springframework.web.context.support.WebApplicationContextUtils;
ApplicationContext ac1 = WebApplicationContextUtils.getRequiredWebApplicationContext(ServletContext sc);
ApplicationContext ac2 = WebApplicationContextUtils.getWebApplicationContext(ServletContext sc);
ac1.getBean("beanId");
ac2.getBean("beanId");
说明：
这种方式适合于采用Spring框架的B/S系统，通过ServletContext对象获取ApplicationContext对象，然后在通过它获取需要的类实例。

上面两个工具方式的区别是，前者在获取失败时抛出异常，后者返回null。

方法三：继承自抽象类ApplicationObjectSupport
说明：抽象类ApplicationObjectSupport提供getApplicationContext()方法，可以方便的获取到ApplicationContext。
Spring初始化时，会通过该抽象类的setApplicationContext(ApplicationContext context)方法将ApplicationContext 对象注入。

方法四：继承自抽象类WebApplicationObjectSupport
说明：类似上面方法，调用getWebApplicationContext()获取WebApplicationContext

方法五：实现接口ApplicationContextAware
说明：实现该接口的setApplicationContext(ApplicationContext context)方法，并保存ApplicationContext 对象。
Spring初始化时，会通过该方法将ApplicationContext对象注入。

虽然，spring提供了后三种方法可以实现在普通的类中继承或实现相应的类或接口来获取spring 的ApplicationContext对象，但是在使用是一定要注意实现了这些类或接口的普通java类一定要在Spring 的配置文件application-context.xml文件中进行配置。否则获取的ApplicationContext对象将为null。

如下是我实现了ApplicationContextAware接口的例子

package quartz.util;

import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

public class SpringConfigTool implements ApplicationContextAware{//extends ApplicationObjectSupport{

private static ApplicationContext context = null;
private static SpringConfigTool stools = null;
public synchronized static SpringConfigTool init(){
  if(stools == null){
   stools = new SpringConfigTool();
  }
  return stools;
}

public void setApplicationContext(ApplicationContext applicationContext)
throws BeansException {
  context = applicationContext;
}

public synchronized static Object getBean(String beanName) {
return context.getBean(beanName);
}

}

XML文件中的配置信息

最后提供一种不依赖于servlet,不需要注入的方式
注意一点，在服务器启动时，Spring容器初始化时，不能通过以下方法获取Spring 容器，如需细节可以观看源码org.springframework.web.context.ContextLoader

Title

1 import org.springframework.web.context.ContextLoader;
2 import org.springframework.web.context.WebApplicationContext;
3
4     WebApplicationContext wac = ContextLoader.getCurrentWebApplicationContext();
5     wac.getBean(beanID);

岁月神偷 2010-10-09 10:18 发表评论

maven

岁月神偷 — Fri, 08 Oct 2010 07:10:00 GMT

maven依赖关系中Scope的作用 Dependency Scope
在POM .xml中，中还引入了，它主要管理依赖的部署。

目前可以使用5个值：
    * compile，缺省值，适用于所有阶段，会随着项目一起发布。
    * provided，类似compile，期望JDK、容器或使用者会提供这个依赖。如servlet.jar。
    * runtime，只在运行时使用，如JDBC驱动，适用运行和测试阶段。
    * test，只在测试时使用，用于编译和运行测试代码。不会随项目发布。
    * system，类似provided，需要显式提供包含依赖的jar，Maven不会在Repository中查找它。

岁月神偷 2010-10-08 15:10 发表评论

Spring 自定义搜索，注解BEAN

岁月神偷 — Wed, 06 Oct 2010 12:31:00 GMT

Filter Types

Filter Type	Example Expression	Description
annotation	`org.example.SomeAnnotation`	An annotation to be present at the type level in target components.
assignable	`org.example.SomeClass`	A class (or interface) that the target components are assignable to (extend/implement).
aspectj	`org.example..*Service+`	An AspectJ type expression to be matched by the target components.
regex	`org\.example\.Default.*`	A regex expression to be matched by the target components class names.
custom	`org.example.MyTypeFilter`	A custom implementation of the `org.springframework.core.type .TypeFilter` interface.

xml

1 <beans>
2
3    <context:component-scan base-package="org.example">
4       <context:include-filter type="regex" expression=".*Stub.*Repository"/>
5       <context:exclude-filter type="annotation"
6                               expression="org.springframework.stereotype.Repository"/>
7    context:component-scan>
8
9 beans>

岁月神偷 2010-10-06 20:31 发表评论

Spring 注解@Transactional

岁月神偷 — Wed, 06 Oct 2010 12:03:00 GMT

在使用@Transactional注解前需于下配置,两种方式都可以。

xml

JAVA

1 @Repository
2 public class TxService {
3     private DataSourceTransactionManager txManager;
4
5     @Resource(name="dataSource")
6     public void setDataSource(DataSource dataSource) {
7         txManager=new DataSourceTransactionManager(dataSource);
8         // configure the AnnotationTransactionAspect to use it; this must be done before executing any transactional methods
9         AnnotationTransactionAspect.aspectOf().setTransactionManager(txManager);
10     }
11
12     public DataSourceTransactionManager getTxManager() {
13         return txManager;
14     }
15
16 }

@Transactional使用实例

  // these settings have precedence for this method
@Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
public void updateFoo(Foo foo) {
// do something
}

@Transactional 可配置属性

Property	Type	Description
`value`	String	Optional qualifier specifying the transaction manager to be used.
`propagation`	enum: `Propagation`	Optional propagation setting.
`isolation`	enum: `Isolation`	Optional isolation level.
`readOnly`	boolean	Read/write vs. read-only transaction
`timeout`	int (in seconds granularity)	Transaction timeout.
`rollbackFor`	Array of `Class` objects, which must be derived from`Throwable.`	Optional array of exception classes that must cause rollback.
`rollbackForClassname`	Array of class names. Classes must be derived from`Throwable.`	Optional array of names of exception classes that must cause rollback.
`noRollbackFor`	Array of `Class` objects, which must be derived from`Throwable.`	Optional array of exception classes that must not cause rollback.
`noRollbackForClassname`	Array of `String` class names, which must be derived from`Throwable.`	Optional array of names of exception classes that must notcause rollback.

岁月神偷 2010-10-06 20:03 发表评论