Advisor

Spring事务传播及数据库事务操作

此生再无相见时 提交于 2021-02-12 18:54:50
从Spring 事务配置说起   先看看Spring 事务的基础配置 <aop:aspectj-autoproxy proxy-target- class = " true " />   <bean id= " transactionManager "      class = " org.springframework.jdbc.datasource.DataSourceTransactionManager " >     <property name= " dataSource " ref = " dataSource " />   </bean>   <tx:annotation-driven transaction-manager= " transactionManager " />   <!-- 配置事务传播特性-->   <tx:advice id= " transactionAdvice " transaction-manager= " transactionManager " >     <tx:attributes>       <tx:method name= " add* " propagation= " REQUIRED "       rollback - for = " Exception,RuntimeException,SQLException "

设计模式-适配器模式

这一生的挚爱 提交于 2021-01-06 11:52:08
适配器模式 智者千虑必有一失,愚者千虑必有一得 在我们做设计的时候总是会出现一些 意外 ,适配器模式就是帮我们来弥补这些意外的 定义 变压模式,也叫包装模式,但是包装模式可不止一个。装饰者也是。 功能是将 一个类的接口编程客户端所期望的另一个接口,从而使原本接口不匹配而无法在一起工作的两个类能够一起工作 属于结构型设计模式 例子 Switch的港版电压在国内是不适用的,需要两脚转三角插头 有点亡羊补牢的感觉 通用写法 类适配器 Target目标角色 ​ 该角色定义把其他类转换为何种接口,也就是我们的期望接口,例 子中的IUserInfo接口就是目标角色。 public interface Target { int request(); } ​ 目标角色是一个已经在正式运行的角色,你不可能去修改角色中的方法,你能做的就是如何去实现接口中的方法,而且通常情况下,目标角色是一个接口或者是抽象类,一般不会是实现类。 Adaptee源角色 ​ 你想把谁转换成目标角色,这个“谁”就是源角色,它是已经存在的、运行良好的类或对象,经过适配器角色的包装,它会成为一个崭新、靓丽的角色。 public class Adaptee{ public int specificRequest() { return 220; } } Adapter适配器角色 ​ 适配器模式的核心角色

Spring注解驱动开发之AOP

穿精又带淫゛_ 提交于 2020-12-29 20:03:44
  前言:现今SpringBoot、SpringCloud技术非常火热,作为Spring之上的框架,他们大量使用到了Spring的一些底层注解、原理,比如@Conditional、@Import、@EnableXXX等。如果掌握这些底层原理、注解,那么我们对这些高层框架就能做到高度定制,使用的游刃有余   本篇主要内容:Spring AOP的使用及其原理分析 一、AOP功能测试 AOP【动态代理】:指在程序运行期间动态的将某段代码切入到指定方法指定位置进行运行的编程方式 步骤:    1、导入aop模块;Spring AOP:(spring-aspects)   2、定义一个业务逻辑类(MathCalculator);在业务逻辑运行的时候将日志进行打印(方法之前、方法运行结束、方法出现异常,xxx)    public class MathCalculator { public int div(int i,int j){ System.out.println("MathCalculator...div..."); return i/j; } }   3、定义一个日志切面类(LogAspects):切面类里面的方法需要动态感知MathCalculator.div运行到哪里然后执行; / 切面类 @author lfy @Aspect: 告诉Spring当前类是一个切面类 /

Spring注解驱动开发之十四——AOP原理分析(二)Annotation...AutoProxyCreator 实现时机

筅森魡賤 提交于 2020-12-29 19:11:36
本文包含以下内容: postProcessBeforeInstantiation 执行时机 postProcessBeforeInstantiation 的具体作用 目标方法div执行流程一:获取拦截器链 目标方法div执行流程二: 拦截器链的调用流程分析 AOP 总结 前文回顾: 《 Spring注解驱动开发之十三——AOP原理分析(一)@EnableAspectJAutoProxy注解干了什么 》 上文说到,通过 @EnableAspectJAutoProxy 注解,将通过注册器往Spring中注册一个 AnnotationAwareAspectJAutoProxyCreator 实例化对象,并且讨论了AnnotationAwareAspectJAutoProxyCreator 的继承关系。 本文将紧接上文,进行断点调试在 registerBeanPostProcessors 函数之后讨论, AnnotationAwareAspectJAutoProxyCreator 实例化组件如何实现AOP 的功能。 1.postProcessBeforeInstantiation 执行时机 在 postProcessBeforeInstantiation 函数添加断点,查看执行时机 调用栈如图所示: 1)<init>:84,

优化 Azure 成本,实现财务目标

南楼画角 提交于 2020-12-13 06:59:11
点击上方蓝字关注“汪宇杰博客” 原文:Omar Khan General Manager, Microsoft Azure 翻译:汪宇杰 导语 我们的许多客户都面临着如何满足关键 IT 项目的资金需求的困难决策。我们在此共同帮助您实现财务目标。确保 Azure 工作负载的成本得到优化有助于释放资金,以支持远程工作等基本激增区域。 根据 Flexera 的 2020 年 云服务状况报告 ,成本优化连续第四年成为云的最高优先级计划 https://info.flexera.com/SLO-CM-REPORT-State-of-the-Cloud-2020 今天,我们将介绍 Azure 工具、产品/服务和指导,这些工具、优惠和指南可帮助您管理和优化云成本。您将学习如何理解和预测您的账单、成本优化您的Azure资源以及控制您的支出。然后,我们将向您展示您现在可以做的七件事开始节省成本。 理解和预测您的成本 若要管理和优化 Azure 成本,首先需要了解现在的支出,并预测当前和计划的项目将来可能花费的帐单。 Azure Cost Management + Billing (成本管理 – 计费)为您提供了一套完整的云成本管理功能。您可以使用成本管理 – 计费: 监视和分析 Azure 帐单 设置预算和支出警报 为团队和项目分配额度

【转】SpringBoot 注解事务声明式事务

﹥>﹥吖頭↗ 提交于 2020-12-05 06:58:19
文章来源: http://www.cnblogs.com/guozp/articles/7446477.html   springboot 对新人来说可能上手比springmvc要快,但是对于各位从springmvc转战到springboot的话,有些地方还需要适应下,尤其是xml配置。我个人是比较喜欢注解➕xml是因为看着方便,查找方便,清晰明了。但是xml完全可以使用注解代替,今天就扒一扒springboot中事务使用注解的玩法。   springboot的事务也主要分为两大类,一是xml声明式事务,二是注解事务,注解事务也可以实现类似声明式事务的方法,关于注解声明式事务,目前网上搜索不到合适的资料,所以在这里,我将自己查找和总结的几个方法写到这里,大家共同探讨 文章来源: http://www.cnblogs.com/guozp/articles/7446477.html springboot 之 xml事务 可以使用 @ImportResource("classpath:transaction.xml") 引入该xml的配置,xml的配置如下    <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http:

Spring中异步注解@Async的使用、原理及使用时可能导致的问题

自作多情 提交于 2020-11-25 05:57:11
前言 最近,很多同学碰到了下面这个问题,添加了Spring提供的一个异步注解 @Async 循环依赖无法被解决了,下面是一些读者的留言跟群里同学碰到的问题: 本着讲一个知识点就要讲明白、讲透彻的原则,我决定单独写一篇这样的文章对 @Async 这个注解做一下详细的介绍,这个注解带来的问题远远不止循环依赖这么简单,如果对它不够熟悉的话建议慎用。 文章要点 @Async的基本使用 这个注解的作用在于可以让被标注的方法异步执行,但是有两个前提条件 1. 配置类上添加@EnableAsync注解 2. 需要异步执行的方法的所在类由Spring管理 3. 需要异步执行的方法上添加了@Async注解 我们通过一个Demo体会下这个注解的作用吧 第一步,配置类上开启异步: @EnableAsync @Configuration @ComponentScan ( "com.dmz.spring.async" ) public class Config { } 第二步, @Component // 这个类本身要被Spring管理 public class DmzAsyncService { @Async // 添加注解表示这个方法要异步执行 public void testAsync () { try { TimeUnit.SECONDS.sleep( 1 ); } catch

Spring AOP

杀马特。学长 韩版系。学妹 提交于 2020-11-21 13:32:08
Spring整合单元测试 在前面的案例中我么需要自己创建ApplicationContext对象,然后在调用getBean来获取需要测试的Bean Spring提供了一种更加方便的方式来创建测试所需的ApplicationContext,并且可以帮助我们把需要测试的Bean直接注入到测试类中 添加依赖: <dependency> <groupId>org.springframework</groupId> <artifactId>spring-test</artifactId> <version>5.2.2.RELEASE</version> </dependency> 测试代码: import org.junit.Test; import org.junit.runner.RunWith; import org.springframework.test.context.ContextConfiguration; import org.springframework.test.context.junit4.SpringJUnit4ClassRunner; import javax.annotation.Resource; @RunWith(SpringJUnit4ClassRunner.class)//固定写法 @ContextConfiguration("classpath

spring boot 全局事务配置

微笑、不失礼 提交于 2020-11-11 21:44:55
我发现很多开源的springBoot项目,使用事务都是 直接使用 事务注解。并没有配置全局事务的。 其实目前现在不是新人程序员就以为 事务就只能靠加注解来控制了。根本没听说过全局事务配置。 网上很多全局事务其实都是不够好的。都是抄来抄去的。真的不知道能不能用。 其实这样很不好的。 写代码的时候如果漏了加上事务注解,那异常不回滚太可怕了 如果写代码的时候都需要手动加上注解,多费事啊。配置全局事务注解多省事。 配置代码 package com.door.config; import org.aspectj.lang.annotation.Aspect; import org.springframework.aop.Advisor; import org.springframework.aop.aspectj.AspectJExpressionPointcut; import org.springframework.aop.support.DefaultPointcutAdvisor; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.context.annotation.Bean; import org.springframework.context

10种AWS成本优化最佳实践

荒凉一梦 提交于 2020-10-30 07:19:56
对于现有的成本优化的 问题,最常见的“解决方案”是调整大小,计划和购买预留实例以实现可预测的工作负载。 这三个“解决方案”可能是大多数AWS用户熟悉的AWS成本优化最佳实践,但不一定是“最佳”实践。有时,他们无法节省声称的成本的一小部分,而许多其他通常被忽视的AWS成本优化最佳实践可以节省更多。 10种AWS成本优化最佳实践 1.调整EC2实例的大小 正如我们已经提到的调整大小,调度和保留实例一样,让我们从这三个AWS成本优化最佳实践开始。调整大小的目的是使实例大小与其工作负载相匹配。不幸的是,由于实例的容量每增加一倍,容量就不能那样工作。 因此,只有在某些实例的峰值利用率不超过〜45%的情况下,调整大小才是值得的最佳实践。仍然值得分析利用率指标,以寻找机会将工作负载转移到更适合其需求的不同系列(“通用”之外)。 解决方案: 在某些实例的峰值利用率(最好是结合CPU和内存一起)不超过〜45%的情况下,调整大小才是值得的最佳实践 2.安排开/关时间 值得安排非生产实例(例如用于开发和测试的实例)的开/关时间,因为如果您应用“按时”计划(从上午8.00到8.00),您将节省运行这些实例的65%的时间下午星期一到星期五。但是,可以节省更多的钱,尤其是如果开发团队以不规则的方式或不规则的时间工作。 您可以通过分析利用率指标来确定更经常使用的实例,从而应用更为激进的调度