web.xml文件中加载Spring配置文件路径：
<!--加载spring文件--> <context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath*:spring/*.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener>
获取数据源：
<!--常量配置文件读入--> <bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> <property name="locations"> <list> <value>classpath*:config/jdbc.properties</value> <value>classpath*:config/hibernate.properties</value> <value>classpath*:config/mail.properties</value> </list> </property> </bean>
上面这段代码还可以简化成如下代码：
<context:property-placeholder
location="classpath:config/hibernate.properties" />
PropertyPlaceholderConfigurer类和context:property-placeholder元素在spring里面所起的作用是相同的，都是加载常量配置文件，只是context:property-placeholder元素更简化。
事务在软件中扮演了一个重要的角色，用于确保数据和资源永远不会处在一种不一致的状态下。
事务的描述ACID：
原子性：确保在事务中的所有操作要么都发生，要么都不发生。
一致性：数据应当不会被破坏。
隔离性：允许多名用户草组同一个数据，一名用户的操作不会和其他用户的操作相混淆。隔离通常意味着要锁定数据库里的记录行和(或)表。
持久性：一旦事务完成，事务的结果应该持久化。通常把事务的结果保存在数据库中。
如果应用程式只使用单一的持久化资源，那么Spring就可以使用持久化机制本身所提供的事务管理支持。这些持久性机制包括JDBC、
Hibernate、JDO、以及Apache的OJB等。然后，如果应用程序跨越多个资源，那么Spring也可以使用第三方的JTA实现支持分布式事务。
不管你是选择在你的Bean里编写事务还是像切面(Aspect,AOP概念)那样声明他们，你都将使用一个Spring事务管理器连接特定平台的
事务实现。
Spring不直接管理事务，相反，他提供了很多可供选择的事务管理器，将事务管理的责任委托给油JTA或相应的持久性机制锁提供的
某个特定平台事务实现。常用的事务管理器有：
DataSourceTransactionManager、orm.hibernate.HibernateTransactionManager、orm.hibernate3.HibernateTransactionManager等，
详见《Spring in action》P149。
下面在程序上下文中声明事务管理器：
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean>
如果使用Hibernate2，那么你就会希望使用HibernateTransactionManager，使用如下XML来申明：
<bean id="transactionManager" class="oag.springframework.orm.hibernate.HibernateTransactionManager"> <property name="sessionFactory" ref="sessionFactory"/> </bean>
如果使用Hibernate3，那么你就会希望使用HibernateTransactionManager，使用如下XML来申明：
<bean id="transactionManager" class="oag.springframework.orm.hibernate3.HibernateTransactionManager"> <property name="sessionFactory" ref="sessionFactory"/> </bean>
===================================start1==========================================
在Spring类代码中直接编写事务代码：
添加事务的一种方式是，利用Spring的TransactionTemplate，在addRant()方法内直接通过编程来添加事务边界，
public void addRant(Rant rant) {
transactionTemplate.execute(
new TransactionCallback() {
public Object doInTransaction(TransactionStatus ts) {
try {
rant.setPostedDate(new Date());
Vehicle existingVehicle = rantDao.findVehicleByPlate(rantVehicle.getState(),rantVehicle.getPlateNumber());
if (existingVehicle != null) {
rant.setVehicle(existingVehicle);
} else {
rantDao.saveVehicle(rantVehicle);
}
rantDao.saveRant(rant);
} catch (Exception e) {
ts.setRollbackOnly();
}
return null;
}
}
}
在上面一段代码中，要想使用TransactionTemplate，必须从实现TransactionCallback接口开始。由于TransactionCallback只有一
个方法需要实现，因此把它作为一个匿名的内部类来实现通常是最容易的。
这里的TransactionTemplate事例是被注入到RantServiceImpl中的：
<bean id="rantService" class="com.roadrantz.service.RantServiceImpl"> ... <property name="transactionTemplate"> <bean class="org.springframework.transaction.support.TransactionTemplate"> <property name="transactionManager" ref="transactionManager"/> </bean> </property> <bean/>
================================================end1=======================================================
Spring对声明式事务管理的支持是通过它的AOP框架来实现的。以前，Spring一直通过使用Spring AOP代理Bean来支持声明式事务。
但是Spring2.0增加了两种新的声明式事务：简单的XML声明(XML-declared)事务和注释驱动(annotation-driven)事务。
下面会着重讲解这三种方式：
首先来了解下定义事务参数：
1、传播行为：传播行为定义关于客户端和被调用方法的事务边界。常用参数例如：PROPAGATION_REQUIRES_NEW、PROPAGATION_MANDATORY,
传播行为回答了这样一个问题：就是一个新的事务应该被启动环视被挂起，或者是一个方法是否应该在事务性上下文中运行。
2、隔离级别：定义一个事务可能受其他并发事务活动影响的程度，可以把他想象为那个事务对于事务处理数据的自私程度。
并发导致的问题：赃读、不可重复读、幻读
考虑到完全隔离会影响性能，而且并不是所有应用程序都要求完全隔离，所以有时可以在事务隔离方面灵活处理，所以就会有好几个
隔离级别，常用的有：ISOLATION_DEFAULT、ISOLATION_READ_UNCOMMITTED
3、只读：如果一个事务支队后端数据库执行读操作，那么该数据库就可能可以利用那个事务的只读特性，采取某些优化措施。通过
把一个事务声明为只读，可以给后端数据库一个机会来应对哪些它认为合适的优化措施。
4、事务超时：你可以声明一个事务，在特定秒数之后自动回滚，而不必等它自己结束。只对那些可能开启新事务的传播行为才有意义。
5、回滚规则：他们定义那些异常引起回滚，那些不引起。不过，你可以声明一个事务在出现特定的受阻异常时像运行时异常一样回滚。
同样，你可以声明一个事务在出现特定的异常时不回滚，即使那些异常是运行时异常。
===========================================start方式1===============================================
在2.0之前的Spring版本中，声明式事务管理通过使用Spring的TransactionProxyFactoryBean代理POJO来完成。
TransactionProxyFactoryBean是ProxyFactoryBean的一个特化，它知道如何通过用事务性边界包裹一个POJO的方法来处理它们。
下面展示可以怎样声明一个包裹RantServiceImpl类的TransactionProxyFactoryBean：
<!--为target生成一个代理，通过代理调用目标方法--> <bean id="rantService" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> <!--装配事务目标，目标为rantServiceTarget，指向RantServiceImplBean。需要把RantServiceImplBean声明Bean时的名称 修改为rantServiceTarget--> <property name="target" ref="rantServiceTarget"/> <!--指定代理接口。生成的代理要实现的接口--> <property name="proxyInterfaces" value="com.roadrantz.service.RantService"/> <!--装配进事务管理器，配置前面提到的任意一个事务管理器都行。--> <property name="transactionManager" ref="transactionManager"/> <!--配置事务规则、边界，事务规则的相关参数--> <property name="transactionAttributes"> <props> <prop key="add*">PROPAGATION_REQUIRED</prop> <prop key="*">PROPAGATION_SUPPORTS,readOnly</prop> </props> </property> </bean>
这意味着TransactionProxyFactoryBean生成的那个代理必须伪装成一个rant服务。那正是proxyInterfaces属性的目的。
这里我们正在告诉TransactionProxyFactoryBean，生成一个实现RantService接口的代理。
这个transactionAttributes属性值的一提，它声明哪些方法将在一个事务内执行，以及相应的事务参数将是什么。具体详见
《Spring in action》P159。
如果采用上面的方式，使用TransactionProxyFactoryBean代理单个服务Bean没问题。但是如果应用程序中有多个服务Bean，而且它
们都必须在事务中处理，那么该怎么办呢？一个一个写？啰嗦死你。
幸运的是，你不必那样做。利用Spring的功能，创建抽象Bean和“子Bean”，即可在一个位置定义事务策略，然后把他们重复应用到
所有的服务Bean(这种方式比上一种方式更简洁)。
下面首先创建TransactionProxyFactoryBean的一个抽象声明(创建事务管理服务的一个代理抽象声明)：
<bean id="txProxyTemplate" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean" abstract="true"> <property name="transactionManager" ref="transactionManager"/> <property name="transactionAttributes"> <props> <prop key="add*">PROPAGATION_REQUIRED</prop> <prop key="*">PROPAGATION_SUPPORTS,readOnly</prop> </props> </property> </bean>
有了这个抽象的TransactionProxyFactoryBean声明，现在通过把txProxyTemplate用作相应bean的父声明，就可以使得任意数量的
bean事务化了。比如下面这段XML为这里的rant服务扩展txProxyTemplate:
<bean id="rantService" parent="txProxyTemplate"> <property name="target" ref="rantServiceTarget"/> <property name="proxyINterfaces" value="com.roadrantz.service.RantService"/> </bean>
===========================================end方式1===============================================
===========================================start方式2===============================================
TransactionProxyFactoryBean的问题是，使用它会导致极其冗长的Spring配置文件。
好消息是Spring2.0专门为声明式事务提供了一些新的配置元素。这些元素位于tx名称空间，而且可以通过向你的Spring配置XML文件
添加spring-tx-2.0.xsd模式来使用：
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd">
这个tx名称空间提供少量新的XML配置元素，其中最值得注意的是<tx:advice>元素。下列XML片段演示如何使用<tx:advice>来声明
事务性策略：
<tx:advice id="txAdvice" transaction-manager="txManager"> <tx:attributes> <tx:method name="add*" propagation="REQUIRED"/> <tx:method name="*" propagation="SUPPORTS" read-only="true"/> </tx:attributes> </tx:advice>
<tx:method>有几个参数，有助于为指定的方法定义事务策略，具体参数及说明见《Spring in Action》P161
在使用<tx:advice>声明一个事务时，你仍将需要一个事务管理器，就像是使用TransactionProxyFactoryBean时那样。根据配置
惯例，<tx:advice>假定事务管理器会被声明为一个id为transactionManager的Bean，如果你们事务管理器确实叫这个名称的话
那就不用再手动配置了，系统默认就找这个名称的事务管理器。如果你碰巧给你的事务管理器赋予了一个
不同的id(比如说，txManager)，那么你将需要在transactionmanager参数中指定这个事务管理器的id。
上面使用<tx:advice>定义了事务通知，不是一个完整的事务性切面。我们还需要在<tx:advice>中指出哪些Bean应该被通知--我们
需要一个用于该项工作的切入点(Point)。下面定义一个通知器(advisor)作为切入点，它利用这里的txAdvice通知来通知实现
RantService接口的所有Bean：
<aop:config> <aop:advisor pointcut="execution(* *..RantService.*(..))" advice-ref="txAdvice"/> </aop:config>
这里的pointcot参数使用一个AspectJ切入点表达式来指出，这个通知器应该通知RantService接口的所有方法。
===========================================end方式2===============================================
===========================================start方式3===============================================
<tx:advice>元素大大简化了Spring中声明式事务所需的XML。但是假如采用注解的方式还能更简化，你乐意不？
实际上你只需要向你的Spring上下文增加一行XML，即可声明事务。
声明采用注解来实现事务处理：
<tx:annotation-driven transaction-manager="txManager"/>
(事务管理器参数transaction-manager的默认值为transactionManager，如果自己的事务管理器配置的就叫transactionManager，
那么就不需要在这里配置这个参数来指定事务管理器了。而如果不叫这个，就必须在这里使用这个参数来声明事务管理器了)
<tx:annotation-driven>配置元素告诉Spring在类层面或者是方法层面检查应用程序上下文中的所有Bean，并且寻找标注了
@Transactional的Bean。对于每一个标注了@Transactional的Bean，<tx:annotation-driven>将自动把事务通知的内容通知
给它。这个通知的事务参数将由@Transactional注释的参数来定义。
例如(注释那个要事务化的rant服务)：
@Transactional(propagation=Propagation.SUPPORTS,readOnly=true)
public class RantServiceImpl implements RantService {
...
@Transactional(propagation=Propagation.REQUIRED,readOnly=false)
public void addRant(Rant rant) {
...
}
...
}
在类层面上，RantServiceImpl已经被标注了一个@Transactional注释，说明所有方法都将支持事务并且是只读的。
可能有意思的是，@Transactional注释也可以被应用到一个接口上。例如：
@Transactional(propagation=Propagation.SUPPORTS,readOnly=true)
public interface RantService {
...
void addRant(Rant rant);
...
}
通过注释RantService而不是RantServiceImpl，可以指明RantService的所有实现都应该被事务化。
===========================================end方式3===============================================
mongo是没有事务一说的，比如说系统里的一个写的事务，针对大白库有写的操作，在进入service的时候会给它分配写库的连接，这个service里会给大白写库的某个表录入一条数据，同时也会给mongo库里的某个表了录入一条数据，假如这个service中途抛异常了，那么针对mysql录入的那条数据不会做commit操作，会callback，所以这条数据最终不会入库，但是针对mongo库录入的那条数据不会回滚了，mongo没有事务一说。
spring的声明式事务是针对整个方法来说的，例如系统里面的一个写的事务，连接的大白的写库，会在写库里某个表录入一条数据，并且往某个文件里面io写一些文字内容，并且里面也有mongo库的操作，会往mongo某个表里录入一条数据，一旦抛出异常，操作大白写库的操作会回滚，操作mongo库的操作肯定是回滚不了了，即使事务失败了mongo里面也会多出来一条数据，往文件里面写数据这个不知道是否能回滚，我自己想的应该是回滚不了，写进去就写进去了，因为针对数据库的操作可以在真正事务commit的时候再实际操作变更数据库，而针对文件的io操作没有这种事务的commit机制啊，它只有要么操作，要么不操作，没有说等会再操作。当然这种情况可以自己试下！
只有写的数据库连接才会涉及到事务，有commit和collback一说，读的数据库连接不会涉及到事务，读出来就读出来了，对原有数据不会有影响。
自己测试操作的结果：
在读库事务的service方法中可以有写操作，也就是在读库事务中同样可以操作写库，读写库各一个事务，互不影响。
读写库：
一个service方法被匹配到哪个库上的事务配置，到这个service方法里就会针对这个库相关的所有session操作做事务控制，针对其它库的操作是不受事务控制的，针对当前这个service方法
匹配到的事务对应的库的所有数据库连接(session)用的应该都是同一个，同一个session
重点示例：
1、在findB() service方法中调用saveA()方法。假如当前这个方法被匹配到的事务(读库事务)声明了只读(read-only)，那么在这个方法里只有针对这个库相关的连接操作只读，针对其它库
的连接操作(例如调用写库的saveB() service方法)还是可以照常执行的，事务的传播级别是针对同一个库的不同事务而言的，这里不同的库不受事务的传播级别影响，所以肯定不会沿用原来
那个事务(也用不了，因为不是同一个库的事务)，所以这里操作写库还会自动开启针对写库的事务，并且出问题了自动回滚。假如这里的读操作出问题了，写操作没有问题，而且写库的操作
代码在出问题代码前边，也就是说写库的代码已经执行完了才出的问题，那么读库的事务会回滚，针对写库的操作会正常执行(如果写库的代码在出问题代码的后边，也就是说写库的代码根本
没执行就出问题了，那么写的操作最后也是不会执行的，相当于还没开启写的事务呢就出问题了)。就是这么个结果。
2、在一个saveA() 的service方法中，根据这个方法名称会匹配到它受写库的事务控制，也就是说这个service方法里凡是通过获取写库连接去对写库做操作的地方都会受事务控制，也就是
这个方法里针对写库sessionFactory给分配的session受事务控制，而且应该用的都是同一个session，正是通过分配的session去做的事务控制。我猜的没错的话，所有这个方法里对写库的
操作系统会控制sessionFactory给他们分配的session应该是同一个session，以此来方便控制事务。而如果这个方法里出现操作读库的例如findB()的service方法的调用的话，由于操作这个
读库的操作与鉴定这个方法受事务保护(写库事务)对应的那个库不是同一个库。所以针对这个读库的操作系统会重新开启针对读库的事务，并且这个读库的事务和写库的事务完全没有一毛钱
的关系，相互直接根本不会有事务传播级别相关的关系，而且在这个方法里面针对读库的session应该用的都是同一个(用的都是同一个读库的数据库连接，和写库那个是完全区分开的)。
也即是说这一个方法里现在包含了针对两个不同的库的两个不同的事务，这两个事务相互没有任何关系，也不会有任何影响。如果读事务出现问题了，会回滚，但是不会影响写事务，只要是写
的代码被执行了，那么写事务提交的时候就会正常执行。如果写事务出现问题了，会回滚，但是不会影响读事务。但是话说回来，好像针对读库的事务没有太大的意义，失不失败它都能正常
的读出数据来，不知道咱们系统里面配置这个有什么意义。这里是对现有大白系统做读写分离的一个解说
事务控制是在同一个库的同一个数据库连接上做的，而针对不同的数据库，不可能使用同一个数据库连接，所以针对不同的数据库，不可能在同一个事务里面控制，只能是不同的数据库
操作在不同的事务里面进行。而且所谓的事务传播级别也不可能在不同的数据库事务之间进行生效传递，只对同一个数据库里的事务才生效，才可以传递。
事务是通过session控制事务的，不是这个session对应的库的连接就不受这个事务控制。当然调用其他库的操作的方法有可能会新开启事务，和当前这个方法对应的事务完全没有任何关系。
事务的传播级别是针对同一个库的事务而言的，不同的库之间的事务没有任何关系，而且不同的库之间的事务也不会有传播级别这么一说，不同库之间的事务根本不能复用，因为里面包含的
数据库连接指向的数据库都不是同一个。
注意：针对那种一个service方法里有io文件读写操作的，或者比如异步开启一个定时任务这种，在事务回滚的时候，这种非数据库操作的各种类型的操作会回滚吗？？？这个可以试一下！！！！
注意：针对那种比如一个service方法里面有两个不同的mysql库的操作的这种，如果中间抛出异常了，这个两个库的操作都会回滚是吗？？？这个需要自己试一下，不知道！！！
注意：假如一个service方法里的数据库操作做了try catch捕获操作了，假如抛异常了，在catch里自己处理了，外面的service层感知不到，这种的事务会回滚吗？？spring配置的事务是遇到异常就回滚吗？还是说只是针对service层能感知到的已经跑出到service层的异常才会回滚？？？？这个需要自己试一下！！
spring里面事务的传播属性和事务隔离级别
一、Propagation （事务的传播属性）
Propagation ： key属性确定代理应该给哪个方法增加事务行为。这样的属性最重要的部份是传播行为。有以下选项可供使用：
PROPAGATION_REQUIRED--支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。
PROPAGATION_SUPPORTS--支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY--支持当前事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW--新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED--以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER--以非事务方式执行，如果当前存在事务，则抛出异常。
1： PROPAGATION_REQUIRED
加入当前正要执行的事务不在另外一个事务里，那么就起一个新的事务
比如说，ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED, 那么由于执行ServiceA.methodA的时候，
ServiceA.methodA已经起了事务，这时调用ServiceB.methodB，ServiceB.methodB看到自己已经运行在ServiceA.methodA的事务内部，就不再起新的事务。而假如ServiceA.methodA运行的时候发现自己没有在事务中，他就会为自己分配一个事务。这样，在ServiceA.methodA或者在ServiceB.methodB内的任何地方出现异常，事务都会被回滚。即使ServiceB.methodB的事务已经被提交，但是ServiceA.methodA在接下来fail要回滚，ServiceB.methodB也要回滚
2： PROPAGATION_SUPPORTS
如果当前在事务中，即以事务的形式运行，如果当前不再一个事务中，那么就以非事务的形式运行
3： PROPAGATION_MANDATORY
必须在一个事务中运行。也就是说，他只能被一个父事务调用。否则，他就要抛出异常
4： PROPAGATION_REQUIRES_NEW
这个就比较绕口了。 比如我们设计ServiceA.methodA的事务级别为PROPAGATION_REQUIRED，ServiceB.methodB的事务级别为PROPAGATION_REQUIRES_NEW，那么当执行到ServiceB.methodB的时候，ServiceA.methodA所在的事务就会挂起，ServiceB.methodB会起一个新的事务，等待ServiceB.methodB的事务完成以后，他才继续执行。他与PROPAGATION_REQUIRED 的事务区别在于事务的回滚程度了。因为ServiceB.methodB是新起一个事务，那么就是存在两个不同的事务。如果ServiceB.methodB已经提交，那么ServiceA.methodA失败回滚，ServiceB.methodB是不会回滚的。如果ServiceB.methodB失败回滚，如果他抛出的异常被ServiceA.methodA捕获，ServiceA.methodA事务仍然可能提交。
5： PROPAGATION_NOT_SUPPORTED
当前不支持事务。比如ServiceA.methodA的事务级别是PROPAGATION_REQUIRED ，而ServiceB.methodB的事务级别是PROPAGATION_NOT_SUPPORTED ，那么当执行到ServiceB.methodB时，ServiceA.methodA的事务挂起，而他以非事务的状态运行完，再继续ServiceA.methodA的事务。
6： PROPAGATION_NEVER
不能在事务中运行。假设ServiceA.methodA的事务级别是PROPAGATION_REQUIRED， 而ServiceB.methodB的事务级别是PROPAGATION_NEVER ，那么ServiceB.methodB就要抛出异常了。
7： PROPAGATION_NESTED
理解Nested的关键是savepoint。他与PROPAGATION_REQUIRES_NEW的区别是，PROPAGATION_REQUIRES_NEW另起一个事务，将会与他的父事务相互独立，而Nested的事务和他的父事务是相依的，他的提交是要等和他的父事务一块提交的。也就是说，如果父事务最后回滚，他也要回滚的。
二、Isolation Level(事务隔离等级):
1、Serializable：最严格的级别，事务串行执行，资源消耗最大；
2、REPEATABLE READ：保证了一个事务不会修改已经由另一个事务读取但未提交（回滚）的数据。避免了“脏读取”和“不可重复读取”的情况，但是带来了更多的性能损失。
3、READ COMMITTED:大多数主流数据库的默认事务等级，保证了一个事务不会读到另一个并行事务已修改但未提交的数据，避免了“脏读取”。该级别适用于大多数系统。
4、Read Uncommitted：保证了读取过程中不会读取到非法数据。隔离级别在于处理多事务的并发问题。
我们知道并行可以提高数据库的吞吐量和效率，但是并不是所有的并发事务都可以并发运行，这需要查看数据库教材的可串行化条件判断了。这里就不阐述。
我们首先说并发中可能发生的3中不讨人喜欢的事情
1： Dirty reads--读脏数据。也就是说，比如事务A的未提交（还依然缓存）的数据被事务B读走，如果事务A失败回滚，会导致事务B所读取的的数据是错误的。
2： non-repeatable reads--数据不可重复读。比如事务A中两处读取数据-total-的值。在第一读的时候，total是100，然后事务B就把total的数据改成 200，事务A再读一次，结果就发现，total竟然就变成200了，造成事务A数据混乱。
3： phantom reads--幻象读数据，这个和non-repeatable reads相似，也是同一个事务中多次读不一致的问题。但是non-repeatable reads的不一致是因为他所要取的数据集被改变了（比如total的数据），但是phantom reads所要读的数据的不一致却不是他所要读的数据集改变，而是他的条件数据集改变。比如Select account.id where account.name="ppgogo*",第一次读去了6个符合条件的id，第二次读取的时候，由于事务b把一个帐号的名字由"dd"改成"ppgogo1"，结果取出来了7个数据。
三、readOnly
事务属性中的readOnly标志表示对应的事务应该被最优化为只读事务。
这是一个最优化提示。在一些情况下，一些事务策略能够起到显著的最优化效果，例如在使用Object/Relational映射工具（如：Hibernate或TopLink）时避免dirty checking（试图“刷新”）。
四、Timeout
在事务属性中还有定义“timeout”值的选项，指定事务超时为几秒。在JTA中，这将被简单地传递到J2EE服务器的事务协调程序，并据此得到相应的解释