首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

【面试】Spring事务面试考点整理

Spring和事务的关系 关系型数据库、某些消息队列等产品或中间件称为事务性资源,因为它们本身支持事务,也能够处理事务。 Spring很显然不是事务性资源,但是它可以管理事务性资源,所以Spring和事务之间是管理关系。 就像Jack Ma虽然不会写代码,但是他却管理者一大批会写代码的码农。 Spring事务三要素 数据源:表示具体的事务性资源,是事务的真正处理者,如MySQL等。 事务管理器:像一个大管家,从整体上管理事务的处理过程,如打开、提交、回滚等。 事务应用和属性配置:像一个标识符,表明哪些方法要参与事务,如何参与事务,以及一些相关属性如隔离级别、超时时间等。 Spring事务的注解配置 把一个DataSource(如DruidDataSource)作为一个@Bean注册到Spring容器中,配置好事务性资源。 把一个@EnableTransactionManagement注解放到一个@Configuration类上,配置好事务管理器,并启用事务管理。 把一个@Transactional注解放到类上或方法上,可以设置注解的属性,表明该方法按配置好的属性参与到事务中。 事务注解的本质 @Transactional这个注解仅仅是一些(和事务相关的)元数据,在运行时被事务基础设施读取消费,并使用这些元数据来配置bean的事务行为。 大致来说具有两方面功能,一是表明该方法要参与事务,二是配置相关属性来定制事务的参与方式和运行行为。 Spring声明式事务实现原理 声明式事务成为可能,主要得益于Spring AOP。使用一个事务拦截器,在方法调用的前后/周围进行事务性增强(advice),来驱动事务完成。 如何回滚一个事务 就是在一个事务上下文中当前正在执行的代码里抛出一个异常,事务基础设施代码会捕获任何未处理的异常,并且做出决定是否标记这个事务为回滚。 默认回滚规则 默认只把runtime, unchecked exceptions标记为回滚,即RuntimeException及其子类,Error默认也导致回滚。Checked exceptions默认不导致回滚。这些规则和EJB是一样的。 如何配置回滚异常 使用@Transactional注解的rollbackFor/rollbackForClassName属性,可以精确配置导致回滚的异常类型,包括checked exceptions。 noRollbackFor/noRollbackForClassName属性,可以配置不导致回滚的异常类型,当遇到这样的未处理异常时,照样提交相关事务。 事务注解在类/方法上 @Transactional注解既可以标注在类上,也可以标注在方法上。当在类上时,默认应用到类里的所有方法。如果此时方法上也标注了,则方法上的优先级高。 事务注解在类上的继承性 @Transactional注解的作用可以传播到子类,即如果父类标了子类就不用标了。但倒过来就不行了。 子类标了,并不会传到父类,所以父类方法不会有事务。父类方法需要在子类中重新声明而参与到子类上的注解,这样才会有事务。 事务注解在接口/类上 @Transactional注解可以用在接口上,也可以在类上。在接口上时,必须使用基于接口的代理才行,即JDK动态代理。 事实是Java的注解不能从接口继承,如果你使用基于类的代理,即CGLIB,或基于织入方面,即AspectJ,事务设置不会被代理和织入基础设施认出来,目标对象不会被包装到一个事务代理中。 Spring团队建议注解标注在类上而非接口上。 只在public方法上生效? 当采用代理来实现事务时,(注意是代理),@Transactional注解只能应用在public方法上。当标记在protected、private、package-visible方法上时,不会产生错误,但也不会表现出为它指定的事务配置。可以认为它作为一个普通的方法参与到一个public方法的事务中。 如果想在非public方法上生效,考虑使用AspectJ(织入方式)。 目标类里的自我调用没有事务? 在代理模式中(这是默认的),只有从外部的方法调用进入通过代理会被拦截,这意味着自我调用(实际就是,目标对象中的一个方法调用目标对象的另一个方法)在运行时不会导致一个实际的事务,即使被调用的方法标有注解。 如果你希望自我调用也使用事务来包装,考虑使用AspectJ的方式。在这种情况下,首先是没有代理。相反,目标类被织入(即它的字节码被修改)来把@Transactional加入到运行时行为,在任何种类的方法上都可以。 事务与线程 和JavaEE事务上下文一样,Spring事务和一个线程的执行相关联,底层是一个ThreadLocal<Map<Object, Object>>,就是每个线程一个map,ke

02
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    【面试】Spring事务面试考点吐血整理(建议珍藏)

    Spring和事务的关系 关系型数据库、某些消息队列等产品或中间件称为事务性资源,因为它们本身支持事务,也能够处理事务。 Spring很显然不是事务性资源,但是它可以管理事务性资源,所以Spring和事务之间是管理关系。 就像Jack Ma虽然不会写代码,但是他却管理者一大批会写代码的码农。 Spring事务三要素 数据源:表示具体的事务性资源,是事务的真正处理者,如MySQL等。 事务管理器:像一个大管家,从整体上管理事务的处理过程,如打开、提交、回滚等。 事务应用和属性配置:像一个标识符,表明哪些方法要参与事务,如何参与事务,以及一些相关属性如隔离级别、超时时间等。 Spring事务的注解配置 把一个DataSource(如DruidDataSource)作为一个@Bean注册到Spring容器中,配置好事务性资源。 把一个@EnableTransactionManagement注解放到一个@Configuration类上,配置好事务管理器,并启用事务管理。 把一个@Transactional注解放到类上或方法上,可以设置注解的属性,表明该方法按配置好的属性参与到事务中。 事务注解的本质 @Transactional这个注解仅仅是一些(和事务相关的)元数据,在运行时被事务基础设施读取消费,并使用这些元数据来配置bean的事务行为。 大致来说具有两方面功能,一是表明该方法要参与事务,二是配置相关属性来定制事务的参与方式和运行行为。 Spring声明式事务实现原理 声明式事务成为可能,主要得益于Spring AOP。使用一个事务拦截器,在方法调用的前后/周围进行事务性增强(advice),来驱动事务完成。 如何回滚一个事务 就是在一个事务上下文中当前正在执行的代码里抛出一个异常,事务基础设施代码会捕获任何未处理的异常,并且做出决定是否标记这个事务为回滚。 默认回滚规则 默认只把runtime, unchecked exceptions标记为回滚,即RuntimeException及其子类,Error默认也导致回滚。Checked exceptions默认不导致回滚。这些规则和EJB是一样的。 如何配置回滚异常 使用@Transactional注解的rollbackFor/rollbackForClassName属性,可以精确配置导致回滚的异常类型,包括checked exceptions。 noRollbackFor/noRollbackForClassName属性,可以配置不导致回滚的异常类型,当遇到这样的未处理异常时,照样提交相关事务。 事务注解在类/方法上 @Transactional注解既可以标注在类上,也可以标注在方法上。当在类上时,默认应用到类里的所有方法。如果此时方法上也标注了,则方法上的优先级高。 事务注解在类上的继承性 @Transactional注解的作用可以传播到子类,即如果父类标了子类就不用标了。但倒过来就不行了。 子类标了,并不会传到父类,所以父类方法不会有事务。父类方法需要在子类中重新声明而参与到子类上的注解,这样才会有事务。 事务注解在接口/类上 @Transactional注解可以用在接口上,也可以在类上。在接口上时,必须使用基于接口的代理才行,即JDK动态代理。 事实是Java的注解不能从接口继承,如果你使用基于类的代理,即CGLIB,或基于织入方面,即AspectJ,事务设置不会被代理和织入基础设施认出来,目标对象不会被包装到一个事务代理中。 Spring团队建议注解标注在类上而非接口上。 只在public方法上生效? 当采用代理来实现事务时,(注意是代理),@Transactional注解只能应用在public方法上。当标记在protected、private、package-visible方法上时,不会产生错误,但也不会表现出为它指定的事务配置。可以认为它作为一个普通的方法参与到一个public方法的事务中。 如果想在非public方法上生效,考虑使用AspectJ(织入方式)。 目标类里的自我调用没有事务? 在代理模式中(这是默认的),只有从外部的方法调用进入通过代理会被拦截,这意味着自我调用(实际就是,目标对象中的一个方法调用目标对象的另一个方法)在运行时不会导致一个实际的事务,即使被调用的方法标有注解。 如果你希望自我调用也使用事务来包装,考虑使用AspectJ的方式。在这种情况下,首先是没有代理。相反,目标类被织入(即它的字节码被修改)来把@Transactional加入到运行时行为,在任何种类的方法上都可以。 事务与线程 和JavaEE事务上下文一样,Spring事务和一个线程的执行相关联,底层是一个ThreadLocal<Map<Object, Object>>,就是每个线程一个map,ke

    03

    大数据应用管理模式及内容

    通过调研,数据应用管理可总结为分散管理型、职能复用型、集中管理型三种模式,数据应用管理模式中重点关注组织管理、需求管理、建设管理、成果管理四大领域。 (1) 管理模式 分散管理型:各部门分散开展数据应用,无集中管理,例如某某国有集团,公司各业务部门均设有业务数据部门,开展本部门数据应用相关事务。 职能复用型:赋予现有部门数据应用管理职责,集中开展数据应用局部过程的管理事务,例如某工业公司,依托公司信息技能部负责开展公司所有数据应用项目建设。 集中管理型:成立独立于技能和业务部门的实体或虚拟管理组织,集中开展数据应用全过程管理事务,例如某国有银行,设立设置与技能部门平级的数据管理部统筹开展全行数据管理和应用。 (2) 管理内容 组织管理:指的是数据应用管理的组织形式,可总结为如下几类: 实体组织型:成立独立于技能和业务部门的数据应用实体管理组织,集中开展数据应用管理事务。 虚拟组织型:由技能、业务部门共同组成数据应用管理虚拟组织, 集中开展数据应用管理事务。 职能复用型:赋予现有部门数据应用管理职责,负责集中开展数据应用局部过程的管理事务。 需求管理:指的是数据应用的需求管理形式,可总结为如下几类: 基于项目型:通过抑制企业级数据管理权,集中开展大数据应用需求管理。 基于数据型: 通过抑制大数据应用分析项目,集中开展大数据应用需求管理。 建设管理:指的是数据应用建设的管理模式,可总结为如下几类: 系统建设项目管理方式:系统建设驱动,沿用常规信息化项目建设管理模式,对方案设计、研发、上线运行等环节进行管理。 大数据项目管理方式:数据分析驱动,根据大数据应用特点,重点对数据需求统筹、模型持续迭代等内容进行管理。 成果管理:指的是数据应用成果的管理模式,可总结为如下几类: 建设方法共享:指共享大数据应用建设方法,共享内容包括建设方案、分析模型、程序等过程文件及经提炼后的经验和知识等。 分析结果共享:指数据应用分析结果的共享。 3.2 各管理模式的优劣势对比 分散管理、职能复用、集中管理三种管理模式各有优缺点,适用于不同业务类型、不同规模的企业。 (1) 分散管理 企业级数据管控能力弱:企业很难全局掌握抑制数据应用行为; 数据应用成本高:虽然数据应用管理成本低,但由于反复建设及成果不能共享导致企业总体数据应用成本偏高; 数据应用创新能力强:对数据应用建设及使用的约束较少,有利于促进数据应用的创新。 (2) 职能复用 企业级数据管控能力一般:由于现有部门职能的单一性,无法在企业级对数据应用的全过程管控;数据应用成本高:无法从全过程统筹管理数据应用建设,仍会导致反复建设及成果不能共享的情况; 数据应用创新能力一般:对数据应用建设及使用进行局部规范和约束,一定程度上影响了数据应用的创新。 (3) 集中管理 企业级数据管控能力强:企业可对数据应用全局、全过程的掌握和抑制; 数据应用成本低:虽数据应用管理成本相对较高,但由于实现企业级需求统筹、成果共享,数据应用成本总体不高; 数据应用创新能力强:实现了需求统筹、成果共享,变成了企业级数据应用创新机制,促进了数据应用创新能力的提升。 人工智能、大数据、云计算和物联网的未来发展值得重视,均为前沿产业,有兴趣的朋友,可以查阅多智时代

    01

    Spring 声明式事务

    Spring 的声明式事务顾名思义就是采用声明的方式来处理事务。这里所说的声明,就是指在配置文件中声明。用在 Spring 配置文件中声明式的处理事务来代替代码式的处理事务。这样的好处是,事务管理不侵入开发的组件,具体来说,业务逻辑对象就不会意识到正在事务管理之中,事实上也应该如此,因为事务管理是属于系统层面的服务,而不是业务逻辑的一部分,如果想要改变事务管理策划的话,也只需要在定义文件中重新配置即可;在不需要事务管理的时候,只要在设定文件上修改一下,即可移去事务管理服务,无需改变代码重新编译,这样维护起来极其方便。Spring 使用 AOP 来完成声明式的事务管理,因而声明式事务是以方法为单位,Spring 的事务属性自然就在于描述事务应用至方法上的策略。关于事务的基础知识请移步 ☛ MySQL 事务

    01
    领券