面试题 ------ 框架部分

1、什么事框架？

    框架（Framework）是一个框架————指约束性，也是一个架子————指器支撑性
    
    IT 语境中的框架，特指为解决一个开放性问题而设计得具有一定约束性的支撑结构，在此结构上可以根据具体问题扩展、安插更多的组成部分，从而更迅速和方便地构建完整的解决问题的方案。
    1、框架本身一般不完整到可以解决特定问题，但是可以帮助您快速解决特定问题：
        没有框架所有工作都从零开始做，有了框架，为我们提供了一定的功能，我们就可以在框架的基础上开发，极大的解放了生产力。
    2、框架天生就是为扩展而设计得
    3、框架里面可以为后续扩展的组件提供很多辅助性、支撑性的方便易用的实用工具（utilities），也就是说框架时常配套了一些帮助解决某类问题的库（libraries）或工具（tools）。
   
     在Java 中就是一系列的jar 包，其本质就是对jdk 功能的扩展。

2、MVC 模式

    MVC 全称是Model View Controller， 是模型（model）—— 视图（view）—— 控制器（controller）的缩写，一种软件设计规范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互同时，不需要重新编写业务逻辑
    最简单的、最经典就是Jsp（view） + Servlet（controller） + JavaBean（model）

1、当控制器收到来自用户的请求
2、控制器调用javaBean 完成业务
3、完成业务后，通过控制器跳转页面的方式给用户反馈信息
4、jsp 用户做出响应

控制器是核心

3、什么事MVC 框架？

    是为了解决传统MVC 模式（jsp + servlet + javabean）问题而出现的框架。

传统MVC 模式问题：
    1、所有得Servlet 和servlet 映射都要配置在web.xml 中，如果项目太大，web.xml就太庞大，并且不能实现模块化管理
    2、Servlet 的主要功能就是接受参数、调用逻辑、跳转页面、比如像其他字符编码、文件上传等功能也要卸载Servle 中，不能让Servlet 主要功能而需要做处理一下特例。
    3、接受参数比较麻烦（request.getParameter("name"),User user = new User(); user.setName(name);），不能通过model 接收，只能单个接收，接收完成后转换封装model。
    4、跳转页面方式比较单一（forward，redirect），并且当我们页面名称发生改变时需要修改Servlet 源代码

现在比较常用的MVC 框架有：
    Struts
    webwork
    Struts2
    SpringMVC

4、简单讲一下struts2 的执行流程？

一个请求在Struts2 框架中的处理大概分为以下几个步骤：
1、客户端浏览器发送请求
2、这个请求经过一系列的过滤器（Filter）（这些过滤器中有一个叫做ActionContextCleanUp的可选过滤器，这个过滤器对于Struts 和其他框架的集成很有帮助，例如：SiteMesh Plugin）
3、接着FilterDispatcher（StrutsPrepareAndExecuteFilter）被使用，FilterDispatcher（StrutsPrepareAndExecuteFilter）询问ActionMapper 来决定这个请求是否需要调用某个Action；
4、如果ActionMapper 决定需要调用某个Action。FilterDispatcher（StrutsPrepareAndExecuteFilter）把请求的处理交给ActionProxy
5、ActionProxy 通过Configuration Manager 询问框架的配置文件，找到需要调用的Action 类；
6、ActionProxy 创建一个ActionInvocation 的实例
7、ActionInvocation 实例使用命名模式来调用，在调用Action 的过程前后，涉及到相关拦截器（Intercepter）的调用
8、一旦Action 执行完毕，ActuonInvocation 负责根据struts.xml 中的配置找到对应的返回结果,返回结果通常是（但不总是，也可能是另外的一个Action 链）一个需要被表示的JSP 或者 FreeMarker 的横版，在表示的过程中可以使用Struts2 框架中继承的标签，在这个过程中需要涉及到ActionMapper。

总结：
    1、浏览器发送请求，经过一系列的过滤器后,到达核心过滤器（StrutsPrepareAndExecuteFiler）
    2、StrutsPrepareAndExecuteFiler 通过ActionMapper 判断当前的请求是否需要某个Action 处理，如果不需要，则走原来的流程，如果需要则把请求交给ActionProxy 来处理
    3、ActionProxy 通过Configuration Manager询问框架的配置文件（Struts.xml）。找到需要调用的Action 类
    4、创建一个ActionInvocation 实例，来调用Action 的对应方法，获取结果集的 name，在调用前后会执行相关拦截器。
    5、通过结果集的Name 知道对应的结果集来对浏览器进行响应。


拦截、判断、寻找、执行、响应

5、Struts2 中的拦截器，你都用它干什么？

    struts2 中的功能（参数处理、文件上传、字符编码等）都是通过系统拦截器实现的。   
    如果业务需要，当然我们也可以自定义拦截器，进行可插拔配置，在执行Action的方法前后、加入相关逻辑完成业务。
    
使用场景：
    1、用户登陆判断、在执行Action 的前面判断是否已经登录，如果没有登陆的跳转到登陆页面。
    2、用户权限判断、在执行Action 的前面判断是否具有，如果没有权限给出提示信息。
    3、操作日志。。。。

6、简单讲一下SpringMVC 的执行流程?

1、用户向服务器发送请求。请求被Spring 前端控制Servelt DispatcherServlet 捕获 （捕获）；
2、DisparcherServlet 对请求URL 进行解析，得到请求资源标示符（URL）。然后根据该URL ，调用HandlerMapping 获得该Handler 配置的所有相关的对象（包括Handler 对象以及Handler 对象对应的拦截器）。最后HandlerExecutionChain 对象的形式返回 （查找handler）；
3、DispatcherServlet 根据获得的Handler，选择一个合适的HandlerAdapter。提取Request 中的模型数据，填充Handler 入参，开始执行Handler（Controller），Handler执行完成后，向DispatcherServlet 返回一个ModelAndView 对象  (执行handler)；
4、DispatcherServlet 根据返回的ModelAndView，选择一个合适的ViewResolver（必须量已经注册到Spring 容器中ViewResolver）（选择viewResolver）；
5、通过ViewResolver 结合Model 和 View，来渲染视图DispatcherServlet 将渲染结果返回给客户端 （渲染返回）；


快速记忆：
核心控制器捕获请求、查找Handler、执行Handler、选择合适的ViewResolver、通过ViewResolver渲染视图并返回

7、说一下struts2 和springMVC 有什么不同？

目前企业中使用SpringMvc 的比例已经远远超过Struts2，那么两者到底有什么区别，是很多初学者比较关注的问题，下面我们就来对SpringMVC 和Struts2 进行各方面的比较：
1、核心控制器（前端控制器、预处理控制器）：对于使用过mvc 框架的人来说这个词应该不会陌生，控制器的主要用途是处理所有得请求，然后对那些特殊请求（控制器）统一得进行处理（字符编码、文件上传、参数接收、异常处理等等），SpringMVC 核心控制器是Servlet，而Struts2 是Filter。
2、控制器实例：SpringMVC 会比Struts快一些（理论上），SpringMVC 是基于方法设计，而Struts 是基于对象，每次发一次请求都会实例一个action， 每一个action 都会被注入属性，而Spring更像Servlet一样，只有一个实例，每次请求执行对应的方法即可（注意：用于是单例实例，所以应当避免全局变量的修改，这样会产生线程安全问题）
3、管理方式：大部分公司的核心架构中，就会使用到Spring 而SpringMVC 又是spring中的一个模块，所以spring 对于springMVC 的控制管理更加简单方便，而且提供了全注解方式进行管理，各个功能的注解都比较全面，使用简单，而struts2 需要采用XML 很多的配置参数来管理（虽然也可以采用注解，但是几乎没有公司那样使用）
4、参数传递：Struts2 中自身提供很多种参数接受，其实都是通过（ValueStack）进行传递和赋值，而SpringMVC 是通过方法的参数进行接收
5、学习难度：Struts2 中自身提供多种技术点，比如拦截器、值栈及OGNL表达式，学习成本较高，springmvc 比较简单，很较少的时间都能上手
6、intercepter 的实现机制：struts 有以自己的Interceptor 机制，springmvc 用的是独立的AOP 方式，这样导致struts 的配置文件量还是比springmvc 大，虽然struts 的配置能继承，所以我觉得论使用上来讲，springmvc 使用更加简洁，开发效率Springmvc 确实比struts2 高，springmvc 是方法级别的拦截，一个方法对应一个Request 上下文，而方法同时又跟一个url 对应，所以说从框架本身上springmvc 就容易实现restful
url， struts2 是级别的拦截，一个类对应一个request 上下文：实现restful url要费劲，因为strurs2 action 的一个方法可以对应一个url，而其类属性却被所有方法共享，这也就无法用注释其他方式表示其所属方法了，springmvc 的方法之间基本上独立的，独享request response 数据，请求数据通过参数数据获取，处理结果通过ModelMap 交回给框架方法之间不共享变量，而struts2 就比较乱，虽然方法之间也是独立的，但其所有Action 变量是共享，这不会影响程序运行，却给我们编码，读程序时带来麻烦。
7、springmvc 处理ajax 请求，直接通过返回数据，方法中使用注解@ResponseBody，SpringMVC 自动帮我们对象转换为JSON 数据，而struts2 是通过插件方式进行处理。

在SpringMVC 流行起来之前，Struts2 在MVC 框架中占核心地位，随着SpringMVC 的出现。SpringMVC 慢慢的取代Struts，但是很多企业都是原来搭建的框架，使用Struts2 比较

8、说一下Spring 中的两大核心？

    Spring 是一个J2EE 应用程序框架，是轻量级的IOC 和AOP 的容器框架（相对重量级的框架EJB ），主要针对JavaBean 的生命周期进行管理的轻量级容器，可以单独使用，也可以和Struts 框架，ibatis 框架等组合使用
1、IOC（Inversion of Control）或DI（Dependency Injection）
    IOC 控制反转
        原来：我们得Service 需要调用DAO，Service 就需要创建DAO
        Spring：Spring 发现你Service 依赖于dao，就给你注入。
    核心原来：就是容器（map） + 反射（工厂也可以） + 配置文件
2、AOP 面向切面编程
    核心原来：使用动态代理的设计模式在执行方法前后或出现异常后做相关逻辑。
    我们主要使用AOP 来做：
        2.1、事务处理：在执行方法前，开启事务、执行完成后关闭事务、出现异常后回滚事务
        2.2、权限判断：在执行方法前，判断是否具有权限
        2.3、日志：在执行前进行日志处理
        2.4、。。。。

9、Spring 事务的传播特性

1、PROPAGATION_REQUIRED：如果存在一个事务，则支持当前事务，如果没有事务则开启
2、PROPAGATION_SUPPORTS：如果存在一个事务，支持当前事务，如果没有事务，则非事务的执行
3、PROPAGATION_MANDATORY：如果已经存在一个事务，支持当前事务，如果没有一个活动的事务，则抛出异常
4、PROPAGATION_REQUTIRES_NEW：总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起
5、PROPAGATION_NOT_SUPPORTED：总是非事务地执行，并挂起任何存在的事务。
6、PROPAGATION_NEVER:总是非事务地执行，如果存在一个活动事务，则抛出异常
7、PROPAGATION_NESTED：如果一个活动的事务存在，则运行在一个嵌套的事务中，如果没有活动事务，则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行

10、Spring 事务的隔离级别

隔离级别
    声明式事务的第二个方面是隔离级别。隔离级别定义一个事务可能受其他并发事务活动活动影响的程度。另一种考虑一个事务的隔离级别的方式，是把它想象为那个事务对于事物处理数据的自私程度。

    在一个典型的应用程序中，多个事务同时运行，经常会为了完成他们的工作而操作同一个数据。并发虽然是必需的，但是会导致一下问题：

    1、脏读（Dirty read）-- 脏读发生在一个事务读取了被另一个事务改写但尚未提交的数据时。如果这些改变在稍后被回滚了，那么第一个事务读取的数据就会是无效的。
    2、不可重复读（Nonrepeatable read）-- 不可重复读发生在一个事务执行相同的查询两次或两次以上，但每次查询结果都不相同时。这通常是由于另一个并发事务在两次查询之间更新了数据。
    3、幻影读（Phantom reads）-- 幻影读和不可重复读相似。当一个事务（T1）读取几行记录后，另一个并发事务（T2）插入了一些记录时，幻影读就发生了。在后来的查询中，第一个事务（T1）就会发现一些原来没有的额外记录。
    在理想状态下，事务之间将完全隔离，从而可以防止这些问题发生。然而，完全隔离会影响性能，因为隔离经常牵扯到锁定在数据库中的记录（而且有时是锁定完整的数据表）。侵占性的锁定会阻碍并发，要求事务相互等待来完成工作。

    考虑到完全隔离会影响性能，而且并不是所有应用程序都要求完全隔离，所以有时可以在事务隔离方面灵活处理。因此，就会有好几个隔离级别。

隔离级别	含义
ISOLATION_DEFAULT	使用后端数据库默认的隔离级别。
ISOLATION_READ_UNCOMMITTED	允许读取尚未提交的更改。可能导致脏读、幻影读或不可重复读。
ISOLATION_READ_COMMITTED	允许从已经提交的并发事务读取。可防止脏读，但幻影读和不可重复读仍可能会发生。
ISOLATION_REPEATABLE_READ	对相同字段的多次读取的结果是一致的，除非数据被当前事务本身改变。可防止脏读和不可重复读，但幻影读仍可能发生。
ISOLATION_SERIALIZABLE	完全服从ACID的隔离级别，确保不发生脏读、不可重复读和幻影读。这在所有隔离级别中也是最慢的，因为它通常是通过完全锁定当前事务所涉及的数据表来完成的。

只读
    声明式事务的第三个特性是它是否是一个只读事务。如果一个事务只对后端数据库执行读操作，那么该数据库就可能利用那个事务的只读特性，采取某些优化 措施。通过把一个事务声明为只读，可以给后端数据库一个机会来应用那些它认为合适的优化措施。由于只读的优化措施是在一个事务启动时由后端数据库实施的， 因此，只有对于那些具有可能启动一个新事务的传播行为（PROPAGATION_REQUIRES_NEW、PROPAGATION_REQUIRED、 ROPAGATION_NESTED）的方法来说，将事务声明为只读才有意义。
    此外，如果使用Hibernate作为持久化机制，那么把一个事务声明为只读，将使Hibernate的flush模式被设置为FLUSH_NEVER。这就告诉Hibernate避免和数据库进行不必要的对象同步，从而把所有更新延迟到事务的结束。

事务超时
    为了使一个应用程序很好地执行，它的事务不能运行太长时间。因此，声明式事务的下一个特性就是它的超时。
    假设事务的运行时间变得格外的长，由于事务可能涉及对后端数据库的锁定，所以长时间运行的事务会不必要地占用数据库资源。这时就可以声明一个事务在特定秒数后自动回滚，不必等它自己结束。
    由于超时时钟在一个事务启动的时候开始的，因此，只有对于那些具有可能启动一个新事务的传播行为（PROPAGATION_REQUIRES_NEW、PROPAGATION_REQUIRED、ROPAGATION_NESTED）的方法来说，声明事务超时才有意义。

回滚规则
    事务五边形的对后一个边是一组规则，它们定义哪些异常引起回滚，哪些不引起。在默认设置下，事务只在出现运行时异常（runtime exception）时回滚，而在出现受检查异常（checked exception）时不回滚（这一行为和EJB中的回滚行为是一致的）。
    不过，也可以声明在出现特定受检查异常时像运行时异常一样回滚。同样，也可以声明一个事务在出现特定的异常时不回滚，即使那些异常是运行时一场。

扩展阅读
    标题是只有事务的隔离级别和传播机制，却顺带这把声明式事务的五个特性都讲述了一遍。：）

    文章开头说过查看Spring中事务的源码来确认3.0版本及之后事务的传播机制是否减少了，其实在TransactionDefinition这个接口中定义了事务的隔离级别、传播机制、只读以及超时相关的全部信息。源码如下，感兴趣的可以自己对照一下，看看英文注释。

/*
 * Copyright 2002-2010 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.springframework.transaction;

import java.sql.Connection;

/**
 * Interface that defines Spring-compliant transaction properties.
 * Based on the propagation behavior definitions analogous to EJB CMT attributes.
 *
 * <p>Note that isolation level and timeout settings will not get applied unless
 * an actual new transaction gets started. As only {@link #PROPAGATION_REQUIRED},
 * {@link #PROPAGATION_REQUIRES_NEW} and {@link #PROPAGATION_NESTED} can cause
 * that, it usually doesn't make sense to specify those settings in other cases.
 * Furthermore, be aware that not all transaction managers will support those
 * advanced features and thus might throw corresponding exceptions when given
 * non-default values.
 *
 * <p>The {@link #isReadOnly() read-only flag} applies to any transaction context,
 * whether backed by an actual resource transaction or operating non-transactionally
 * at the resource level. In the latter case, the flag will only apply to managed
 * resources within the application, such as a Hibernate <code>Session</code>.
 *
 * @author Juergen Hoeller
 * @since 08.05.2003
 * @see PlatformTransactionManager#getTransaction(TransactionDefinition)
 * @see org.springframework.transaction.support.DefaultTransactionDefinition
 * @see org.springframework.transaction.interceptor.TransactionAttribute
 */
public interface TransactionDefinition {

  /**
   * Support a current transaction; create a new one if none exists.
   * Analogous to the EJB transaction attribute of the same name.
   * <p>This is typically the default setting of a transaction definition,
   * and typically defines a transaction synchronization scope.
   */
  int PROPAGATION_REQUIRED = 0;

  /**
   * Support a current transaction; execute non-transactionally if none exists.
   * Analogous to the EJB transaction attribute of the same name.
   * <p><b>NOTE:</b> For transaction managers with transaction synchronization,
   * <code>PROPAGATION_SUPPORTS</code> is slightly different from no transaction
   * at all, as it defines a transaction scope that synchronization might apply to.
   * As a consequence, the same resources (a JDBC <code>Connection</code>, a
   * Hibernate <code>Session</code>, etc) will be shared for the entire specified
   * scope. Note that the exact behavior depends on the actual synchronization
   * configuration of the transaction manager!
   * <p>In general, use <code>PROPAGATION_SUPPORTS</code> with care! In particular, do
   * not rely on <code>PROPAGATION_REQUIRED</code> or <code>PROPAGATION_REQUIRES_NEW</code>
   * <i>within</i> a <code>PROPAGATION_SUPPORTS</code> scope (which may lead to
   * synchronization conflicts at runtime). If such nesting is unavoidable, make sure
   * to configure your transaction manager appropriately (typically switching to
   * "synchronization on actual transaction").
   * @see org.springframework.transaction.support.AbstractPlatformTransactionManager#setTransactionSynchronization
   * @see org.springframework.transaction.support.AbstractPlatformTransactionManager#SYNCHRONIZATION_ON_ACTUAL_TRANSACTION
   */
  int PROPAGATION_SUPPORTS = 1;

  /**
   * Support a current transaction; throw an exception if no current transaction
   * exists. Analogous to the EJB transaction attribute of the same name.
   * <p>Note that transaction synchronization within a <code>PROPAGATION_MANDATORY</code>
   * scope will always be driven by the surrounding transaction.
   */
  int PROPAGATION_MANDATORY = 2;

  /**
   * Create a new transaction, suspending the current transaction if one exists.
   * Analogous to the EJB transaction attribute of the same name.
   * <p><b>NOTE:</b> Actual transaction suspension will not work out-of-the-box
   * on all transaction managers. This in particular applies to
   * {@link org.springframework.transaction.jta.JtaTransactionManager},
   * which requires the <code>javax.transaction.TransactionManager</code>
   * to be made available it to it (which is server-specific in standard J2EE).
   * <p>A <code>PROPAGATION_REQUIRES_NEW</code> scope always defines its own
   * transaction synchronizations. Existing synchronizations will be suspended
   * and resumed appropriately.
   * @see org.springframework.transaction.jta.JtaTransactionManager#setTransactionManager
   */
  int PROPAGATION_REQUIRES_NEW = 3;

  /**
   * Do not support a current transaction; rather always execute non-transactionally.
   * Analogous to the EJB transaction attribute of the same name.
   * <p><b>NOTE:</b> Actual transaction suspension will not work out-of-the-box
   * on all transaction managers. This in particular applies to
   * {@link org.springframework.transaction.jta.JtaTransactionManager},
   * which requires the <code>javax.transaction.TransactionManager</code>
   * to be made available it to it (which is server-specific in standard J2EE).
   * <p>Note that transaction synchronization is <i>not</i> available within a
   * <code>PROPAGATION_NOT_SUPPORTED</code> scope. Existing synchronizations
   * will be suspended and resumed appropriately.
   * @see org.springframework.transaction.jta.JtaTransactionManager#setTransactionManager
   */
  int PROPAGATION_NOT_SUPPORTED = 4;

  /**
   * Do not support a current transaction; throw an exception if a current transaction
   * exists. Analogous to the EJB transaction attribute of the same name.
   * <p>Note that transaction synchronization is <i>not</i> available within a
   * <code>PROPAGATION_NEVER</code> scope.
   */
  int PROPAGATION_NEVER = 5;

  /**
   * Execute within a nested transaction if a current transaction exists,
   * behave like {@link #PROPAGATION_REQUIRED} else. There is no analogous
   * feature in EJB.
   * <p><b>NOTE:</b> Actual creation of a nested transaction will only work on
   * specific transaction managers. Out of the box, this only applies to the JDBC
   * {@link org.springframework.jdbc.datasource.DataSourceTransactionManager}
   * when working on a JDBC 3.0 driver. Some JTA providers might support
   * nested transactions as well.
   * @see org.springframework.jdbc.datasource.DataSourceTransactionManager
   */
  int PROPAGATION_NESTED = 6;


  /**
   * Use the default isolation level of the underlying datastore.
   * All other levels correspond to the JDBC isolation levels.
   * @see java.sql.Connection
   */
  int ISOLATION_DEFAULT = -1;

  /**
   * Indicates that dirty reads, non-repeatable reads and phantom reads
   * can occur.
   * <p>This level allows a row changed by one transaction to be read by another
   * transaction before any changes in that row have been committed (a "dirty read").
   * If any of the changes are rolled back, the second transaction will have
   * retrieved an invalid row.
   * @see java.sql.Connection#TRANSACTION_READ_UNCOMMITTED
   */
  int ISOLATION_READ_UNCOMMITTED = Connection.TRANSACTION_READ_UNCOMMITTED;

  /**
   * Indicates that dirty reads are prevented; non-repeatable reads and
   * phantom reads can occur.
   * <p>This level only prohibits a transaction from reading a row
   * with uncommitted changes in it.
   * @see java.sql.Connection#TRANSACTION_READ_COMMITTED
   */
  int ISOLATION_READ_COMMITTED = Connection.TRANSACTION_READ_COMMITTED;

  /**
   * Indicates that dirty reads and non-repeatable reads are prevented;
   * phantom reads can occur.
   * <p>This level prohibits a transaction from reading a row with uncommitted changes
   * in it, and it also prohibits the situation where one transaction reads a row,
   * a second transaction alters the row, and the first transaction re-reads the row,
   * getting different values the second time (a "non-repeatable read").
   * @see java.sql.Connection#TRANSACTION_REPEATABLE_READ
   */
  int ISOLATION_REPEATABLE_READ = Connection.TRANSACTION_REPEATABLE_READ;

  /**
   * Indicates that dirty reads, non-repeatable reads and phantom reads
   * are prevented.
   * <p>This level includes the prohibitions in {@link #ISOLATION_REPEATABLE_READ}
   * and further prohibits the situation where one transaction reads all rows that
   * satisfy a <code>WHERE</code> condition, a second transaction inserts a row
   * that satisfies that <code>WHERE</code> condition, and the first transaction
   * re-reads for the same condition, retrieving the additional "phantom" row
   * in the second read.
   * @see java.sql.Connection#TRANSACTION_SERIALIZABLE
   */
  int ISOLATION_SERIALIZABLE = Connection.TRANSACTION_SERIALIZABLE;


  /**
   * Use the default timeout of the underlying transaction system,
   * or none if timeouts are not supported. 
   */
  int TIMEOUT_DEFAULT = -1;


  /**
   * Return the propagation behavior.
   * <p>Must return one of the <code>PROPAGATION_XXX</code> constants
   * defined on {@link TransactionDefinition this interface}.
   * @return the propagation behavior
   * @see #PROPAGATION_REQUIRED
   * @see org.springframework.transaction.support.TransactionSynchronizationManager#isActualTransactionActive()
   */
  int getPropagationBehavior();

  /**
   * Return the isolation level.
   * <p>Must return one of the <code>ISOLATION_XXX</code> constants
   * defined on {@link TransactionDefinition this interface}.
   * <p>Only makes sense in combination with {@link #PROPAGATION_REQUIRED}
   * or {@link #PROPAGATION_REQUIRES_NEW}.
   * <p>Note that a transaction manager that does not support custom isolation levels
   * will throw an exception when given any other level than {@link #ISOLATION_DEFAULT}.
   * @return the isolation level
   */
  int getIsolationLevel();

  /**
   * Return the transaction timeout.
   * <p>Must return a number of seconds, or {@link #TIMEOUT_DEFAULT}.
   * <p>Only makes sense in combination with {@link #PROPAGATION_REQUIRED}
   * or {@link #PROPAGATION_REQUIRES_NEW}.
   * <p>Note that a transaction manager that does not support timeouts will throw
   * an exception when given any other timeout than {@link #TIMEOUT_DEFAULT}.
   * @return the transaction timeout
   */
  int getTimeout();

  /**
   * Return whether to optimize as a read-only transaction.
   * <p>The read-only flag applies to any transaction context, whether
   * backed by an actual resource transaction
   * ({@link #PROPAGATION_REQUIRED}/{@link #PROPAGATION_REQUIRES_NEW}) or
   * operating non-transactionally at the resource level
   * ({@link #PROPAGATION_SUPPORTS}). In the latter case, the flag will
   * only apply to managed resources within the application, such as a
   * Hibernate <code>Session</code>.
   * <p>This just serves as a hint for the actual transaction subsystem;
   * it will <i>not necessarily</i> cause failure of write access attempts.
   * A transaction manager which cannot interpret the read-only hint will
   * <i>not</i> throw an exception when asked for a read-only transaction.
   * @return <code>true</code> if the transaction is to be optimized as read-only 
   * @see org.springframework.transaction.support.TransactionSynchronization#beforeCommit(boolean)
   * @see org.springframework.transaction.support.TransactionSynchronizationManager#isCurrentTransactionReadOnly()
   */
  boolean isReadOnly();

  /**
   * Return the name of this transaction. Can be <code>null</code>.
   * <p>This will be used as the transaction name to be shown in a
   * transaction monitor, if applicable (for example, WebLogic's).
   * <p>In case of Spring's declarative transactions, the exposed name will be
   * the <code>fully-qualified class name + "." + method name</code> (by default).
   * @return the name of this transaction
   * @see org.springframework.transaction.interceptor.TransactionAspectSupport
   * @see org.springframework.transaction.support.TransactionSynchronizationManager#getCurrentTransactionName()
   */
  String getName();

}

11、什么事ROM？

    对象关系映射（Object Relational Mapping，简称ROM）模式是一种为了解决面向对象与关系型数据库存在的互不匹配的现象的技术，简单的说，ORM 是通过使用描述对象和数据库之间映射的元数据，将程序中的对象自动持久化到关系数据库中，那么，到底如何实现持久化呢？一种简单的方案是采用硬编码方式（jdbc 操作sql 方式），为每一种可能的数据库访问操作提供单独的方法。
这种方案存在以下不足：
    1、持久化层缺乏弹性，一旦出现业务需求的变更，就必须修改持久化层的接口
    2、持久化层同时与域模型与关系数据库模型绑定，不管模型还是关系数据库模型发生变化，都要修改持久化层的相关程序代码，增加了软件的维护难度。
    ORM 提供了实现持久化层的另一种模式，它采用映射元数据来描述对象关系得映射，使得ORM 中间件能在任何一个应用的业务逻辑层和数据库层充当桥梁。java 典型的ORM 框架有：hibernate，ibatis，speedframework
    ORM的方法论基于三个核心原则：
        简单：以最基本的形式建模数据
        传达性：数据库结构被任何人都能理解的语言文档化
        精确性：基于数据库模型创建正确标准化了的结构


    对象关系映射（Object、 Relational Mapping，简称 ROM）模式是一种为了解决面向对象与关系型数据库存在的互不匹配的现象的技术，可以简单的方案是采用硬编码方式（jdbc 操作 sql方式），为每一种可能的数据库访问操作单独的方式，这种方法存在很多缺陷。

12、ibatis（mybatis） 与 hibernate 有什么不同？

相同点：
    都是java 中的orm 框架，屏蔽jdbc api的底层访问细节，使用我们不用与jdbc api打交道，就可以完成对数据库的持久化操作，jdbc api编程流程固定，还将sql 语句与java 代码混杂在一起，经常需要拼凑sql 语句，细节很繁琐。
    ibatis 的好处：屏蔽jdbc api的底层访问细节，将sql 语句与java 代码进行分类；提供了将结果集自动封装成为实体对象和对象的集合的功能，queryForList 返回对象集合，用queryForObject 返回单个对象；提供了自动将实体对象的属性传递给sql 语句的参数。
    Hibernate 的好处：Hibernate 是一个全自动的orm 映射工具，它可以自动生成sql 语句，并执行返回java 结果

不同点：
    1、hibernate 要比ibatis 功能强大很多，因为Hibernate 自动生成sql 语句
    2、ibatis 需要我们自己在 xml配置文件中写sql 语句，hibernate 我们无法控制该语句。我们就无法去写特定的高效的sql，对于一些不太复杂的sql 查询，hibernate 可以很好帮我们完成，但是，对于特别复杂的查询，hibernate就很难适应了，这时候用ibatis 就不错的选择，因为ibatis 还是我们自己写sql 语句
    3、ibatis 要比hibernate 简单的多，ibatis 是面向sql 的，不同考虑对象间一些复杂的映射关系

13、Hibernate 映射对象的状态？

1、临时状态/瞬时状态（transient）：刚刚用new 语句创建，没有被持久化，无id 不处于session 中（没有使用session 的方法去操作临时对象），该对象称为临时对象；
2、持久化状态/托管状态（persistent）：已经被持久化，加入到session 的缓存中，session 是没有关闭状态的对象为持久化对象；
3、游离状态/脱管状态（detached）：已经被持久化，但不处于session中，该状态的对象为游离状态
4、删除状态（removed）：对象有关联的ID，并且在Session 管理下，但是已经被计划（事务提交得时候，commit()）删除。如果没有事务就不能删除

14、简单讲一下webservice 使用的场景？

    webservice 是一个SOA（面向服务的编程）的架构，它是不依赖于语言，不依赖于平台，可以实现不同的语言间的互相调用，通过Internet 进行基于Http 协议的网络应用间的交互。
    1、异构系统的整合
    2、不同客户端的整合 浏览器、手机端（android、ios、塞班）、微信端、PC端等来访问

例子：天气预报、单点登录

15、简单介绍一下activiti？

    Activiti 是一个业务流程管理器（BPM）和工作流系统，适用于开发人员和系统管理员、其核心是超快速、稳定的BIPMN2 流程引擎，它易于与Spring 集成使用。
   
    主要在OA 中，吧线下流程放到线上，把现实生活中一些流程图定义到系统中，然后通过输入表单数据完成业务。

他可用在OA 系统的流程管理中：请假流程、报销流程

注：内容来源于网络