开涛spring3(9.3) - Spring的事务 之 9.3 编程式事务

9.3  编程式事务

9.3.1  编程式事务概述

       所谓编程式事务指的是通过编码方式实现事务,即类似于JDBC编程实现事务管理。

       Spring框架提供一致的事务抽象,因此对于JDBC还是JTA事务都是采用相同的API进行编程。

 

    Connection conn = null;  
    UserTransaction tx = null;  
    try {  
        tx = getUserTransaction();                       //1.获取事务  
        tx.begin();                                    //2.开启JTA事务  
        conn = getDataSource().getConnection();           //3.获取JDBC  
        //4.声明SQL  
        String sql = "select * from INFORMATION_SCHEMA.SYSTEM_TABLES";  
        PreparedStatement pstmt = conn.prepareStatement(sql);//5.预编译SQL  
        ResultSet rs = pstmt.executeQuery();               //6.执行SQL  
        process(rs);                                   //7.处理结果集  
        closeResultSet(rs);                             //8.释放结果集  
        tx.commit();                                  //7.提交事务  
    } catch (Exception e) {  
        tx.rollback();                                 //8.回滚事务  
        throw e;  
    } finally {  
       conn.close();                                //关闭连接  
    }  

此处可以看到使用UserTransaction而不是Connection连接进行控制事务,从而对于JDBC事务和JTA事务是采用不同API进行编程控制的,并且JTA和JDBC事务管理的异常也是不一样的。

       具体如何使用JTA编程进行事务管理请参考cn.javass.spring.chapter9包下的TranditionalTransactionTest类。

       而在Spring中将采用一致的事务抽象进行控制和一致的异常控制,即面向PlatformTransactionManager接口编程来控制事务。

 

Spring中的事务分为物理事务和逻辑事务;

  • 物理事务:就是底层数据库提供的事务支持,如JDBC或JTA提供的事务;
  • 逻辑事务:是Spring管理的事务,不同于物理事务,逻辑事务提供更丰富的控制,而且如果想得到Spring事务管理的好处,必须使用逻辑事务,因此在Spring中如果没特别强调一般就是逻辑事务;

逻辑事务即支持非常低级别的控制,也有高级别解决方案:

  • 低级别解决方案:

         工具类:使用工具类获取连接(会话)和释放连接(会话),如使用org.springframework.jdbc.datasource包中的 DataSourceUtils 类 来获取和释放具有逻辑事务功能的连接。当然对集成第三方ORM框架也提供了类似的工具类,如对Hibernate提供了 SessionFactoryUtils工具类,JPA的EntityManagerFactoryUtils等,其他工具类都是使用类 似***Utils命名;

//获取具有Spring事务(逻辑事务)管理功能的连接  
DataSourceUtils. getConnection(DataSource dataSource)  
//释放具有Spring事务(逻辑事务)管理功能的连接  
DataSourceUtils. releaseConnection(Connection con, DataSource dataSource)  

TransactionAwareDataSourceProxy使用该数据源代理类包装需要Spring事务管理支持的数据源,该包装类必须位于最外层,主要用于遗留项目中可能直接使用数据源获取连接和释放连接支持或希望在Spring中进行混合使用各种持久化框架时使用,其内部实际使用 DataSourceUtils 工具类获取和释放真正连接;

 

    <!--使用该方式包装数据源,必须在最外层,targetDataSource 知道目标数据源-->  
    <bean id="dataSourceProxy"  
    class="org.springframework.jdbc.datasource.  
    TransactionAwareDataSourceProxy">  
        <property name="targetDataSource" ref="dataSource"/>  
    </bean>  

通过如上方式包装数据源后,可以在项目中使用物理事务编码的方式来获得逻辑事务的支持,即支持直接从DataSource获取连接和释放连接,且这些连接自动支持Spring逻辑事务;

  • 高级别解决方案:

         模板类:使用Spring提供的模板类,如JdbcTemplate、HibernateTemplate和JpaTemplate模板类等,而这些模板类内部其实是使用了低级别解决方案中的工具类来管理连接或会话;

 

Spring提供两种编程式事务支持:直接使用PlatformTransactionManager实现和使用TransactionTemplate模板类,用于支持逻辑事务管理。

如果采用编程式事务推荐使用TransactionTemplate模板类和高级别解决方案。

 

 

9.3.3  使用PlatformTransactionManager

首先让我们看下如何使用PlatformTransactionManager实现来进行事务管理:

1、数据源定义,此处使用第7章的配置文件,即“chapter7/ applicationContext-resources.xml”文件。

 

2、事务管理器定义

    <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">    
        <property name="dataSource" ref="dataSource"/>  
    </bean>  

3、 准备测试环境:

3.1、首先准备测试时使用的SQL

    package cn.javass.spring.chapter9;  
    //省略import  
    public class TransactionTest {  
        //id自增主键从0开始  
        private static final String CREATE_TABLE_SQL = "create table test" +  
        "(id int GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, " +  
        "name varchar(100))";  
        private static final String DROP_TABLE_SQL = "drop table test";  
        private static final String INSERT_SQL = "insert into test(name) values(?)";  
        private static final String COUNT_SQL = "select count(*) from test";  
        ……  
    }  

3.2、初始化Spring容器

    package cn.javass.spring.chapter9;  
    //省略import  
    public class TransactionTest {  
        private static ApplicationContext ctx;  
        private static PlatformTransactionManager txManager;  
        private static DataSource dataSource;  
        private static JdbcTemplate jdbcTemplate;  
        ……  
        @BeforeClass  
        public static void setUpClass() {  
            String[] configLocations = new String[] {  
                    "classpath:chapter7/applicationContext-resources.xml",  
                    "classpath:chapter9/applicationContext-jdbc.xml"};  
            ctx = new ClassPathXmlApplicationContext(configLocations);  
            txManager = ctx.getBean(PlatformTransactionManager.class);  
            dataSource = ctx.getBean(DataSource.class);  
            jdbcTemplate = new JdbcTemplate(dataSource);  
        }   
        ……  
    }  

3.3、使用高级别方案JdbcTemplate来进行事务管理器测试:

    @Test  
    public void testPlatformTransactionManager() {  
        DefaultTransactionDefinition def = new DefaultTransactionDefinition();  
        def.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED);  
        def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);  
        TransactionStatus status = txManager.getTransaction(def);  
        jdbcTemplate.execute(CREATE_TABLE_SQL);  
        try {  
            jdbcTemplate.update(INSERT_SQL, "test");  
            txManager.commit(status);  
        } catch (RuntimeException e) {  
            txManager.rollback(status);  
        }  
        jdbcTemplate.execute(DROP_TABLE_SQL);  
    }  
  • DefaultTransactionDefinition事务定义,定义如隔 离级别、传播行为等,即在本示例中隔离级别为ISOLATION_READ_COMMITTED(提交读),传播行为为 PROPAGATION_REQUIRED(必须有事务支持,即如果当前没有事务,就新建一个事务,如果已经存在一个事务中,就加入到这个事务中)。
  • TransactionStatus事务状态类,通过PlatformTransactionManager的getTransaction方法根据事务定义获取;获取事务状态后,Spring根据传播行为来决定如何开启事务;
  • JdbcTemplate:通过JdbcTemplate对象执行相应的SQL操作,且自动享受到事务支持,注意事务是线程绑定的,因此事务管理器可以运行在多线程环境;
  • txManager.commit(status):提交status对象绑定的事务;
  • txManager.rollback(status):当遇到异常时回滚status对象绑定的事务。

 

3.4、使用低级别解决方案来进行事务管理器测试:

@Test  
public void testPlatformTransactionManagerForLowLevel1() {  
DefaultTransactionDefinition def = new DefaultTransactionDefinition();      def.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED);      def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);  
  TransactionStatus status = txManager.getTransaction(def);  
  Connection conn = DataSourceUtils.getConnection(dataSource);  
  try {  
      conn.prepareStatement(CREATE_TABLE_SQL).execute();  
      PreparedStatement pstmt = conn.prepareStatement(INSERT_SQL);  
      pstmt.setString(1, "test");  
      pstmt.execute();  
      conn.prepareStatement(DROP_TABLE_SQL).execute();  
      txManager.commit(status);  
  } catch (Exception e) {  
      status.setRollbackOnly();  
      txManager.rollback(status);  
  } finally {  
      DataSourceUtils.releaseConnection(conn, dataSource);  
}  
}  

低级别方案中使用DataSourceUtils获取和释放连接,使用txManager开管理事 务,而且面向JDBC编程,比起模板类方式来繁琐和复杂的多,因此不推荐使用该方式。在此就不介绍数据源代理类使用了,需要请参考 platformTransactionManagerForLowLevelTest2测试方法。

 

到此事务管理是不是还很繁琐?必须手工提交或回滚事务,有没有更好的解决方案呢?Spring提供了TransactionTemplate模板类来简化事务管理。

 

9.3.4  使用TransactionTemplate

省略

 

 

9.3.5  事务属性

事务属性通过TransactionDefinition接口实现定义,主要有事务隔离级别、事务传播行为、事务超时时间、事务是否只读。

       Spring提供TransactionDefinition接口默认实现DefaultTransactionDefinition,可以通过该实现类指定这些事务属性。

  • 事务隔离级别用来解决并发事务时出现的问题,其使用TransactionDefinition中的静态变量来指定:

         ISOLATION_DEFAULT:默认隔离级别,即使用底层数据库默认的隔离级别;

         ISOLATION_READ_UNCOMMITTED:未提交读;

         ISOLATION_READ_COMMITTED:提交读,一般情况下我们使用这个;

         ISOLATION_REPEATABLE_READ:可重复读;

         ISOLATION_SERIALIZABLE:序列化。

 

可以使用DefaultTransactionDefinition类的 setIsolationLevel(TransactionDefinition. ISOLATION_READ_COMMITTED)来指定隔离级别,其中此处表示隔离级别为提交读,也可以使用或 setIsolationLevelName(“ISOLATION_READ_COMMITTED”)方式指定,其中参数就是隔离级别静态变量的名字, 但不推荐这种方式。

 

  • 事务传播行为Spring管理的事务是逻辑事务,而且物理事务和逻辑事务最大差别就在于事务传播行为,事务传播行为用于指定在多个事务方法间调用时,事务是如何在这些方法间传播的,Spring共支持7种传播行为:

Required:必须有逻辑事务,否则新建一个事务,使用PROPAGATION_REQUIRED指定,表示如果当前存在一个逻辑事务,则加入该逻辑事务,否则将新建一个逻辑事务,如图9-2和9-3所示;

 

图9-3 Required传播行为抛出异常情况

              在前边示例中就是使用的Required传播行为:

一、在调用userService对象的save方法时,此方法用的是Required传播行为且此时Spring事务管理器发现还没开启逻辑事务,因此Spring管理器觉得开启逻辑事务,

二、在此逻辑事务中调用了addressService对象的save方法,而在save方法中发现同样用的是Required传播行为,因此使用该已经存在的逻辑事务;

三、在返回到addressService对象的save方法,当事务模板类执行完毕,此时提交并关闭事务。

       因此userService对象的save方法和addressService的save方法属于同一个物理事务,如果发生回滚,则两者都回滚。

 

 

RequiresNew:创建新的逻辑事务,使用PROPAGATION_REQUIRES_NEW指定,表示每次都创建新的逻辑事务(物理事务也是不同的)如图9-4和9-5所示:

 

接下来测试一个该传播行为如何执行吧:

1、将如下获取事务模板方式

TransactionTemplate transactionTemplate = TransactionTemplateUtils.getDefaultTransactionTemplate(txManager);  
    TransactionTemplate transactionTemplate = TransactionTemplateUtils.getTransactionTemplate(  
            txManager,   
            TransactionDefinition.PROPAGATION_REQUIRES_NEW,   
            TransactionDefinition.ISOLATION_READ_COMMITTED);  

2、执行如下测试,发现执行结果是正确的:

userService.save(user);  
Assert.assertEquals(1, userService.countAll());  
Assert.assertEquals(1, addressService.countAll()); 

3、修改UserServiceImpl的save方法片段

    userDao.save(user);         
    user.getAddress().setUserId(user.getId());  
    addressService.save(user.getAddress());  

为如下形式,表示userServiceImpl类的save方法将发生回滚,而AddressServiceImpl类的方法由于在抛出异常前执行,将成功提交事务到数据库:

    userDao.save(user);         
    user.getAddress().setUserId(user.getId());  
    addressService.save(user.getAddress());  
    throw new RuntimeException();  

4、修改测试方法片段:

userService.save(user);  
Assert.assertEquals(1, userService.countAll());  
Assert.assertEquals(1, addressService.countAll()); 

为如下形式:

    try {  
        userService.save(user);  
        Assert.fail();  
    } catch (RuntimeException e) {  
    }  
    Assert.assertEquals(0, userService.countAll());  
    Assert.assertEquals(1, addressService.countAll());  

Assert断言中调用userService对象countAll方法返回0,说明该逻辑事务作用域回滚,而调用addressService对象的 countAll方法返回1,说明该逻辑事务作用域正确提交。因此这是不正确的行为,因为用户和地址应该是一一对应的,不应该发生这种情况,因此此处正确 的传播行为应该是Required。

 

该传播行为执行流程(正确提交情况):

一、当执行userService对象的save方法时,由于传播行为是RequiresNew,因此创建一个新的逻辑事务(物理事务也是不同的);

二、当执行到addressService对象的save方法时,由于传播行为是RequiresNew,因此首先暂停上一个逻辑事务并创建一个新的逻辑事务(物理事务也是不同的);

三、addressService对象的save方法执行完毕后,提交逻辑事务(并提交物理事务)并重新恢复上一个逻辑事务,继续执行userService对象的save方法内的操作;

四、最后userService对象的save方法执行完毕,提交逻辑事务(并提交物理事务);

五、userService对象的save方法和addressService对象的save方法不属于同一个逻辑事务且也不属于同一个物理事务。

 

Supports:支持当前事务,使用PROPAGATION_SUPPORTS指定,指如果当前存在逻辑事务,就加入到该逻辑事务,如果当前没有逻辑事务,就以非事务方式执行,如图9-6和9-7所示:

 

NotSupported:不支持事务,如果当前存在事务则暂停该事务,使用PROPAGATION_NOT_SUPPORTED指定,即以非事务方式执行,如果当前存在逻辑事务,就把当前事务暂停,以非事务方式执行,如图9-8和9-9所示:

 

Mandatory:必须有事务,否则抛出异常,使用PROPAGATION_MANDATORY指定,使用当前事务执行,如果当前没有事务,则抛出异常(IllegalTransactionStateException),如图9-10和9-11所示:

 

 

Never:不支持事务,如果当前存在是事务则抛出异常,使用PROPAGATION_NEVER指定,即以非事务方式执行,如果当前存在事务,则抛出异常(IllegalTransactionStateException),如图9-12和9-13所示:

 

Nested:嵌套事务支持,使用PROPAGATION_NESTED指定,如果当前存在事务,则在嵌套事务内执 行,如果当前不存在事务,则创建一个新的事务,嵌套事务使用数据库中的保存点来实现,即嵌套事务回滚不影响外部事务,但外部事务回滚将导致嵌套事务回滚, 如图9-14和9-15所示:

 

Nested和RequiresNew的区别:

1、  RequiresNew每次都创建新的独立的物理事务,而Nested只有一个物理事务;

2、  Nested嵌套事务回滚或提交不会导致外部事务回滚或提交,但外部事务回滚将导致嵌套事务回滚,而 RequiresNew由于都是全新的事务,所以之间是无关联的;

3、  Nested使用JDBC 3的保存点实现,即如果使用低版本驱动将导致不支持嵌套事务。

使用嵌套事务,必须确保具体事务管理器实现的nestedTransactionAllowed属性 为true,否则不支持嵌套事务,如DataSourceTransactionManager默认支持,而 HibernateTransactionManager默认不支持,需要我们来开启。

对于事务传播行为我们只演示了Required和RequiresNew,其他传播行为类似,如果对这些事务传播行为不太会使用,请参考chapter9包下的TransactionTest测试类中的testPropagation方法,方法内有详细示例。

 

  • 事务超时:设置事务的超时时间,单位为秒,默认为-1表示使用底层事务的超时时间;

         使用如setTimeout(100)来设置超时时间,如果事务超时将抛出 org.springframework.transaction.TransactionTimedOutException异常并将当前事务标记为应 该回滚,即超时后事务被自动回滚;

         可以使用具体事务管理器实现的defaultTimeout属性设置默认的事务超时时间,如DataSourceTransactionManager. setDefaultTimeout(10)。

  • 事务只读:将事务标识为只读,只读事务不修改任何数据;

         对于JDBC只是简单的将连接设置为只读模式,对于更新将抛出异常;

         而对于一些其他ORM框架有一些优化作用,如在Hibernate中,Spring事务管理器将执行 “session.setFlushMode(FlushMode.MANUAL)”即指定Hibernate会话在只读事务模式下不用尝试检测和同步持 久对象的状态的更新。

         如果使用设置具体事务管理的validateExistingTransaction属性为true(默认false),将确保整个事务传播链都是只读或都不是只读,如图9-16是正确的事务只读设置,而图9-17是错误的事务只读设置:

 

图9-17 错误的事务只读设置

如图10-17,对于错误的事务只读设置将抛出 IllegalTransactionStateException异常,并伴随“Participating transaction with definition [……] is not marked as read-only……”信息,表示参与的事务只读属性设置错误。

 

 

大家有没有感觉到编程式实现事务管理是不是很繁琐冗长,重复,而且是侵入式的,因此发展到这Spring决定使用配置方式实现事务管理。

 

 

 

 

9.3.6  配置方式实现事务管理

在Spring2.x之前为了解决编程式事务管理的各种不好问题,Spring提出使用配置方式实现事务管理,配置方式利用代理机制实现,即使有TransactionProxyFactoryBean类来为目标类代理事务管理。

 

接下来演示一下具体使用吧:

1、重新定义业务类实现,在业务类中无需显示的事务管理代码:

    package cn.javass.spring.chapter9.service.impl;  
    //省略import  
    public class ConfigAddressServiceImpl implements IAddressService {  
        private IAddressDao addressDao;  
        public void setAddressDao(IAddressDao addressDao) {  
            this.addressDao = addressDao;  
        }  
        @Override  
        public void save(final AddressModel address) {  
            addressDao.save(address);  
        }  
        //countAll方法实现不变  
    }  
    package cn.javass.spring.chapter9.service.impl;  
    //省略import  
    public class ConfigUserServiceImpl implements IUserService {  
        private IUserDao userDao;  
        private IAddressService addressService;  
        public void setUserDao(IUserDao userDao) {  
            this.userDao = userDao;  
        }  
        public void setAddressService(IAddressService addressService) {  
            this.addressService = addressService;  
        }  
        @Override  
        public void save(final UserModel user) {  
            userDao.save(user);  
            user.getAddress().setUserId(user.getId());  
            addressService.save(user.getAddress());  
        }  
        //countAll方法实现不变  
    }  

从以上业务类中可以看出,没有事务管理的代码,即没有侵入式的代码。

 

2.1、首先添加目标类定义:

    <bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">   
        <property name="dataSource" ref="dataSource"/>
    </bean>    

 

<bean id="targetUserService" class="cn.javass.spring.chapter9.service.impl.ConfigUserServiceImpl">  
    <property name="userDao" ref="userDao"/>  
    <property name="addressService" ref="targetAddressService"/>  
</bean>  
<bean id="targetAddressService" class="cn.javass.spring.chapter9.service.impl.ConfigAddressServiceImpl">  
    <property name="addressDao" ref="addressDao"/>  
</bean> 

2.2、配置TransactionProxyFactoryBean类:

<bean id="transactionProxyParent" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean" abstract="true"> <property name="transactionManager" ref="txManager"/> <property name="transactionAttributes"> <props> <prop key="save*"> PROPAGATION_REQUIRED, ISOLATION_READ_COMMITTED, timeout_10, -Exception, +NoRollBackException </prop> <prop key="*"> PROPAGATION_REQUIRED, ISOLATION_READ_COMMITTED, readOnly </prop> </props> </property> </bean>

  • TransactionProxyFactoryBean用于为目标业务类创建代理的Bean;
  • abstract="true"表示该Bean是抽象的,用于去除重复配置;
  • transactionManager事务管理器定义;
  • transactionAttributes表示事务属性定义:
  • PROPAGATION_REQUIRED,ISOLATION_READ_COMMITTED,timeout_10,-Exception,+NoRollBackException事务属性定义,Required传播行为,提交读隔离级别,事务超时时间为10秒,将对所有Exception异常回滚,而对于抛出NoRollBackException异常将不发生回滚而是提交;
  • PROPAGATION_REQUIRED,ISOLATION_READ_COMMITTED,readOnly事务属性定义,Required传播行为,提交读隔离级别,事务是只读的,且只对默认的RuntimeException异常回滚;
  • <prop key="save*">表示将代理以save开头的方法,即当执行到该方法时会为该方法根据事务属性配置来开启/关闭事务;
  • <prop key="*">表示将代理其他所有方法,但需要注意代理方式,默认是JDK代理,只有public方法能代理;

 

注:事务属性的传播行为和隔离级别使用TransactionDefinition静态变量名指定; 事务超时使用“timeout_超时时间”指定,事务只读使用“readOnly”指定,需要回滚的异常使用“-异常”指定,不需要回滚的异常使用“+异 常”指定,默认只对RuntimeException异常回滚。

 

需要特别注意“-异常”和“+异常”中“异常”只是真实异常的部分名,内部使用如下方式判断:

 

//真实抛出的异常.name.indexOf(配置中指定的需要回滚/不回滚的异常名)  
exceptionClass.getName().indexOf(this.exceptionName)  

   因此异常定义时需要特别注意,配置中定义的异常只是真实异常的部分名。

 

 

2.3、定义代理Bean

    <bean id="proxyUserService" parent="transactionProxyParent">  
        <property name="target" ref="targetUserService"/>  
    </bean>  
    <bean id="proxyAddressService" parent="transactionProxyParent">  
        <property name="target" ref="targetAddressService"/>  
    </bean>  

代理Bean通过集成抽象Bean“transactionProxyParent”,并通过target属性设置目标Bean,在实际使用中应该使用该代理Bean。

 

 

3、修改测试方法并测试该配置方式是否好用:

将TransactionTest 类的testServiceTransaction测试方法拷贝一份命名为testConfigTransaction:

并在testConfigTransaction测试方法内将:

 

    IUserService userService =  
    ctx2.getBean("userService", IUserService.class);  
    IAddressService addressService =  
    ctx2.getBean("addressService", IAddressService.class);  
    IUserService userService =  
    ctx2.getBean("proxyUserService ", IUserService.class);  
    IAddressService addressService =  
    ctx2.getBean("proxyAddressService ", IAddressService.class);  

4、执行测试,测试正常通过,说明该方式能正常工作,当调用save方法时将匹配到“<prop key="save*">”定义,而countAll将匹配到“<prop key="save*">”定义,底层代理会应用相应定义中的事务属性来创建或关闭事务。

图9-18 代理方式实现事务管理

       如图9-18,代理方式实现事务管理只是将硬编码的事务管理代码转移到代理中去由代理实现,在代理中实现事务管理。

 

       注:在代理模式下,默认只有通过代理对象调用的方法才能应用相应的事务属性,而在目标方法内的“自我调用”是不会应用相应的事务属性的,即被调用方法不会应用相应的事务属性,而是使用调用方法的事务属性。

 

如图9-19所示,在目标对象targetUserService的save方法内调用事务方法 “this.otherTransactionMethod()”将不会应用配置的传播行为RequriesNew,开启新事务,而是使用save方法的 已开启事务,如果非要这样使用如下方式实现:

 

1、  修改TransactionProxyFactoryBean配置定义,添加exposeProxy属性为true;

2、  在业务方法内通过代理对象调用相应的事务方放,如 “((IUserService)AopContext.currentProxy()).otherTransactionMethod()”即可应用配置的事务属性。

3、  使用这种方式属于侵入式,不推荐使用,除非必要。

 

图9-19 代理方式下的自我调用

 

       配置方式也好麻烦啊,每个业务实现都需要配置一个事务代理,发展到这,Spring想出更好的解决方案,Spring2.0及之后版本提出使用新的“<tx:tags/>”方式配置事务,从而无需为每个业务实现配置一个代理。

 

posted @ 2015-03-05 16:03  crazyYong  阅读(313)  评论(0编辑  收藏  举报