精华内容
下载资源
问答
  • 二、mysql中set autocommit=0与start transaction区别 1、不管autocommit 是1还是0 START TRANSACTION 后,只有当commit数据才会生效,ROLLBACK后就会回滚。 2、当autocommit 为 0 时 不管有没有START TRANSACTION...

    背景:在业务逻辑中,涉及批量update,如果是mysql默认设置下autocommit=1,即多条update语句会一条一条的执行,而不会提交后一起commit,这时候我就想着用set autocommit=0 + update语句 + commit;  事实证明这样确实运行速度快了好几倍,但是也为后面多线程下出现死锁埋下伏笔

    一、报错及解决

    在单元测试没问题后,我用多线程执行了这个处理流程,但是发现偶尔会出现锁错误,经过一番折腾,发现是用这个set autocommit=0导致的,大致原因就是 在mybatis连接数据库中,本次连接的一条语句设置set autocommit=0,那么下面所有语句都会在commit后才会更新到数据库,这就导致了有的语句读和写出现了混乱,算是幻读吧,如下批量跟新:

        <update id="batchUpdate" parameterType="java.util.Map" >
            set autocommit=0;
            <foreach collection="dataMap" item="value" index="key" open="" close="" separator=";">
                update ${region}
                <set >
                    xscj = #{value.xscj,jdbcType=VARCHAR},
                    zqlx = #{value.zqlx,jdbcType=VARCHAR},
                    parent_title = #{value.parent_title,jdbcType=VARCHAR},
                    title = #{value.title,jdbcType=VARCHAR},
                    lawid = #{value.lawid,jdbcType=CLOB},
                    lawidstatus = #{value.lawidstatus,jdbcType=VARCHAR},
                </set>
                where id = #{value.id,jdbcType=INTEGER}
            </foreach>
             ;commit;
        </update>

     报错:

    Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
    ; Deadlock found when trying to get lock; try restarting transaction; nested exception is com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
    	at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.doTranslate(SQLErrorCodeSQLExceptionTranslator.java:267)
    	at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:72)
    	at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:88)
    	at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:440)
    	at com.sun.proxy.$Proxy56.update(Unknown Source)
    	at org.mybatis.spring.SqlSessionTemplate.update(SqlSessionTemplate.java:287)
    	at org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:67)
    	at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:57)
    	at com.sun.proxy.$Proxy57.batchUpdate(Unknown Source)
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    	at java.lang.reflect.Method.invoke(Method.java:498)
    	at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:344)
    	at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:198)
    	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
    
    	at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:139)
    	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
    	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:212)
     Cause: java.sql.SQLException: Table definition has changed, please retry transaction
    ; uncategorized SQLException; SQL state [HY000]; error code [1412]; Table definition has changed, please retry transaction; nested exception is java.sql.SQLException: Table definition has changed, please retry transaction
    	at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:89)
    	at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:81)
    	at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:81)
    	at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:88)
    	at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:440)
    	at com.sun.proxy.$Proxy56.selectList(Unknown Source)
    	at org.mybatis.spring.SqlSessionTemplate.selectList(SqlSessionTemplate.java:223)
    	at org.apache.ibatis.binding.MapperMethod.executeForMany(MapperMethod.java:147)
    	at org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:80)
    	at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:57)
    	at com.sun.proxy.$Proxy57.getDataList(Unknown Source)
    	at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    	at java.lang.reflect.Method.invoke(Method.java:498)
    	at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:344)
    	at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:198)
    	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
    	at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:139)
    	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
    	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:212)
    	at com.sun.proxy.$Proxy58.getDataList(Unknown Source)
    	at com.bdyh.service.AddMissingCont.getDataMap(AddMissingCont.java:32)
    	at com.bdyh.service.HandlerSsyjFlow.hanlFlow(HandlerSsyjFlow.java:24)
    	at com.bdyh.service.HandlerSsyjFlow$$FastClassBySpringCGLIB$$394cc380.invoke(<generated>)
    	at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)

     

    后来改成start transaction后问题解决

    <update id="batchUpdate" parameterType="java.util.Map" >
            start transaction;
            <foreach collection="dataMap" item="value" index="key" open="" close="" separator=";">
                update ${region}
                <set >
                    xscj = #{value.xscj,jdbcType=VARCHAR},
                    zqlx = #{value.zqlx,jdbcType=VARCHAR},
                    parent_title = #{value.parent_title,jdbcType=VARCHAR},
                    title = #{value.title,jdbcType=VARCHAR},
                    lawid = #{value.lawid,jdbcType=CLOB},
                    lawidstatus = #{value.lawidstatus,jdbcType=VARCHAR},
                </set>
                where id = #{value.id,jdbcType=INTEGER}
            </foreach>
             ;commit;
        </update>

    二、mysql中set autocommit=0与start transaction区别

    1、不管autocommit 是1还是0 
         START TRANSACTION 后,只有当commit数据才会生效,ROLLBACK后就会回滚。

     

    2、当autocommit 为 0 时
        不管有没有START TRANSACTION。
        只有当commit数据才会生效,ROLLBACK后就会回滚。

     

    3、如果autocommit 为1 ,并且没有START TRANSACTION 。
        调用ROLLBACK是没有用的。即便设置了SAVEPOINT。

    三、总结

    set autocommit=0与start transaction虽然在批量提交时候都可显著提高速度,但是还是不能乱用,正常来说,start transaction就够用了,set autocommit=0还是不要轻易使用

    展开全文
  • tcc-transaction深入理解

    千次阅读 2020-05-29 18:48:40
    首先tcc如何实现分布式服务的事务一致性的,配置使用的指南中,主要通过Compensable注解开始,首先找到注解的切面,有两个切面,tcc-transaction-spring 的 tcc-transaction.xml配置如下: <!-- 初始化...

    分析的项目为 https://github.com/changmingxie/tcc-transaction

    在项目为dubbo搭配使用,因此全文是在dubbo服务环境进行分析。

    • 首先tcc如何实现分布式服务的事务一致性的,配置使用的指南中,主要通过Compensable注解开始,首先找到注解的切面,有两个切面,tcc-transaction-spring 的 tcc-transaction.xml配置如下:
     <!-- 初始化compensable事物切面 -->
        <bean id="compensableTransactionAspect" class="org.mengyun.tcctransaction.spring.ConfigurableTransactionAspect"
              init-method="init">
            <property name="transactionConfigurator" ref="transactionConfigurator"/>
        </bean>
        <!-- 初始化compensable事物切面 -->
        <bean id="resourceCoordinatorAspect" class="org.mengyun.tcctransaction.spring.ConfigurableCoordinatorAspect"
              init-method="init">
            <property name="transactionConfigurator" ref="transactionConfigurator"/>
        </bean>

    根据getOrder()方法的值,能知道ConfigurableTransactionAspect先行发生于ConfigurableCoordinatorAspect,这一点很重要,他们分别进行了继承操作

    @Aspect
    public class ConfigurableTransactionAspect extends CompensableTransactionAspect implements Ordered ....
    
    @Aspect
    public class ConfigurableCoordinatorAspect extends ResourceCoordinatorAspect implements Ordered ...

    代码最终回到tcc-transaction-core图示代码中,事务的一致从这两个方法和对应的拦截器拉开序幕。

    下面直接通过源码中dubbo例子,来看下正常情况下tcc框架是怎么进行业务逻辑处理的。

    开始之前,请先了解下关联的几个概念。

    //事务方法的角色
    public enum MethodRole {
        ROOT,//root
        CONSUMER,//消费者,框架中尚未使用
        PROVIDER,//提供者
        NORMAL;//普通
    }
    //事务的类型
    public enum TransactionType {
        ROOT(1),
        BRANCH(2);
    
    ...
    //事务的状态
    public enum TransactionStatus {
        //事务的状态,各个执行阶段
        TRYING(1), CONFIRMING(2), CANCELLING(3);
    ....
    //事务
    public class Transaction implements Serializable {
        private TransactionXid xid;//事物id
        private TransactionStatus status;//事物状态
        private TransactionType transactionType;//事物类型
        private List<Participant> participants = new ArrayList<Participant>();//参与者集合
    ....
    //参与者
    public class Participant implements Serializable {
        private TransactionXid xid;//事物id
        private InvocationContext confirmInvocationContext;//确认方法上下文
        private InvocationContext cancelInvocationContext;//取消方法上下文
        Class<? extends TransactionContextEditor> transactionContextEditorClass;
    ....
    
    限于篇幅,以上只列出类中主要使用相关内容,详细内容请查看源码中的内容

    代码从PaymentServiceImpl makePayment 方法开始 涉及的接口和方法有

    @Compensable(confirmMethod = "confirmMakePayment", cancelMethod = "cancelMakePayment")
    PaymentServiceImpl makePayment
    
    @Compensable
    CapitalTradeOrderService record
    @Compensable(confirmMethod = "confirmRecord", cancelMethod = "cancelRecord", transactionContextEditor = DubboTransactionContextEditor.class)
    CapitalTradeOrderServiceImpl record
    
    @Compensable
    RedPacketTradeOrderService record
    @Compensable(confirmMethod = "confirmRecord", cancelMethod = "cancelRecord", transactionContextEditor = DubboTransactionContextEditor.class)
    RedPacketTradeOrderServiceImpl record
    
    //normal即为default操作的统称
    CompensableTransactionInterceptor rootMethodProceed providerMethodProceed normal
    
    ResourceCoordinatorInterceptor enlistParticipant

    下面将用到上面的方法来表示

    https://www.processon.com/view/link/5959a5c6e4b068b0a2406f5f

    详细见processon连接地址,可以看到调用方法时反复在两个拦截器间进行处理,如图为正确处理方法,如果在调用try方法时抛出异常则对ROOT transaction中的参与者依次调用cancelMethod。核心代码为CompensableTransactionInterceptor 的rootMethodProceed方法。

    private Object rootMethodProceed(CompensableMethodContext compensableMethodContext) throws Throwable {
    
            Object returnValue = null;
    
            Transaction transaction = null;
    
            boolean asyncConfirm = compensableMethodContext.getAnnotation().asyncConfirm();
    
            boolean asyncCancel = compensableMethodContext.getAnnotation().asyncCancel();
    
            Set<Class<? extends Exception>> allDelayCancelExceptions = new HashSet<Class<? extends Exception>>();
            allDelayCancelExceptions.addAll(this.delayCancelExceptions);
            allDelayCancelExceptions.addAll(Arrays.asList(compensableMethodContext.getAnnotation().delayCancelExceptions()));
    
            try {
                //开始一个事物,使用UniqueIdentity注解配置的值,在持久层创建了一个事物
                transaction = transactionManager.begin(compensableMethodContext.getUniqueIdentity());
                logger.info(String.format("rootMethodProceed begin transaction %s",JSON.toJSONString(transaction)));
                try {
                    returnValue = compensableMethodContext.proceed();
                } catch (Throwable tryingException) {
                    //如果抛出异常,如果为非声明异常的子类,说明异常则进行回滚
                    if (!isDelayCancelException(tryingException, allDelayCancelExceptions)) {
                        logger.warn(String.format("compensable transaction trying failed. transaction content:%s", JSON.toJSONString(transaction)), tryingException);
                        //方法非预期异常,则进行回滚
                        transactionManager.rollback(asyncCancel);
                    }
    
                    throw tryingException;
                }
    
                //方法正常结束则进行事物提交
                transactionManager.commit(asyncConfirm);
    
            } finally {
                transactionManager.cleanAfterCompletion(transaction);//本地缓存中清除事物
            }
    
            return returnValue;
        }

    如果,在执行confirmMethod方法和cancelMethod方法时抛出,tcc的解决方案是通过定时任务进行补偿执行,具体代码在TransactionRecovery类中,对事务状态为TransactionStatus.CONFIRMING进行再次commit或者是TransactionStatus.CANCELLING或ROOT类型的事务进行再次rollback,这里说明下ROOT类型事务,程序运行期间不管成功还是失败,ROOT类型事务都是会被删除掉,只有极端情况下,比如程序直接挂掉,重启后会对ROOT类型事务进行回滚并删除。

    以上就是文章所有内容,其中还有很多细节,无法一一阐述,本人在原有tcc源码基础编写了一些注释内容,连接如下,但最好还是自己跑一遍源码中提供的例子,改变些参数,添加些日志,以便观察执行的状况。

    https://github.com/patrickWuP/tcc-transaction

     

    展开全文
  • start transaction 指的是启动一个新事务。    在默认的情况下,MySQL从自动提交(autocommit)模式运行,这种模式会在每条语句执行完毕后把它作出的修改立刻提交给数据库并使之永久化。事实

    set autocommit=0,
    当前session禁用自动提交事物,自此句执行以后,每个SQL语句或者语句块所在的事务都需要显示"commit"才能提交事务。

    start transaction

    指的是启动一个新事务。

     

         在默认的情况下,MySQL从自动提交(autocommit)模式运行,这种模式会在每条语句执行完毕后把它作出的修改立刻提交给数据库并使之永久化。事实上,这相当于把每一条语句都隐含地当做一个事务来执行。如果你想明确地执行事务,需要禁用自动提交模式并告诉MySQL你想让它在何时提交或回滚有关的修改。
    执行事务的常用办法是发出一条START TRANSACTION(或BEGIN)语句挂起自动提交模式,然后执行构成本次事务的各条语句,最后用一条 COMMIT语句结束事务并把它们作出的修改永久性地记入数据库。万一在事务过程中发生错误,用一条ROLLBACK语句撤销事务并把数据库恢复到事务开 始之前的状态。

           START TRANSACTION语句"挂起"自动提交模式的含义是:在事务被提交或回滚之后,该模式将恢复到开始本次事务的 START TRANSACTION语句被执行之前的状态。(如果自动提交模式原来是激活的,结束事务将让你回到自动提交模式;如果它原来是禁用的,结束 当前事务将开始下一个事务。)
    如果是autocommit模式  ,autocommit的值应该为 1 ,不autocommit 的值是 0 ;请在试验前 确定autocommit 的模式是否开启 

     

    参考官方文档:http://dev.mysql.com/doc/refman/5.7/en/commit.html


    展开全文
  • transaction、Conference、Workshop的区别

    千次阅读 2019-03-03 13:00:53
    Conference Proceeding和Conference Paper的区别: 在一些会议开完后,会对会议上讨论的文章进行整理和发布。发表了的会议论文被称为Conference Paper,而没有发表的称为Conference Proceeding。因此在引用...

    full paper、short paper、poster、oral:

    而CV界的会议一般分三级:
    oral,需要作者准备PPT上台进行presentation;
    poster,作者贴一张海报,如果有人感兴趣就会到该作者的墙报前面讨论;
    workshop,一般都是某些大牛觉得该领域有哪些方面是研究热点,就向会议chair申请开一个独立的研讨会,值得注意的是workshop是独立审稿的。
    总的来说,这些都算该会议的publication,只是由于接受率不同,所以论文档次也有所不同,一般说来,刚提到的三种文章在同一个会议中档次是降序排列的。

    另外,在数据挖掘,信息检索领域,会议除了一般分为:
    full paper:全文收录;
    short paper:如果审稿人认为作者的文章没那么优秀,但是又没有很强的理由拒绝,就会询问作者是否愿意降格为该类文章(参考会议:CIKM)。啰嗦一句,会议一般不会专门开设一个track让作者投short paper,这与下面要说的poster有所不同。
    poster:通常只有2页,也有可能是上述情况(不同会议的叫法不同),也有可能是作者只希望把自己的idea讲出来,于是特意投了一个poster(参考会议 WWW, SIGIR)

    作者:姜子恒
    链接:http://www.zhihu.com/question/20186384/answer/14262884
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。




    transaction、Conference、Workshop:

    Transactions我们最熟悉的意思是事务,而它还有一个意思被称为“议事录”。一般情况下是某个专业或者学会的议事录,比如:IEEE Transactions on Aerospace and Electronic Systems。Transaction中的文章对于相关背景的介绍比较少,相关理论也会少一点。

    Journal就是期刊的意思,里面的文章对相关背景的介绍会多一些,而且理论深度比较深,因此看起来比较厉害。例如:IEEE/OSA Journal of Display Technology。

    Conference:大家常说的会议。

    Conference Proceeding和Conference Paper的区别:在一些会议开完后,会对会议上讨论的文章进行整理和发布。发表了的会议论文被称为Conference Paper,而没有发表的称为Conference Proceeding。因此在引用Conference Proceeding时不需要标记页码(pp. xx-xx),而引用Conference Paper时就需要标记了。

    workshop,一般都是某些大牛觉得该领域有哪些方面是研究热点,就向会议chair申请开一个独立的研讨会,值得注意的是workshop是独立审稿的。

    展开全文
  • PDO::beginTransaction讲解

    2020-10-17 11:18:51
    今天小编就为大家分享一篇关于PDO::beginTransaction讲解,小编觉得内容挺不错的,现在分享给大家,具有很好的参考价值,需要的朋友一起跟随小编来看看吧
  • 本文就针对项目拆分后数据库的分布式事务问题,基于tcc-transaction分布式TCC型事务进行框架的搭建,同时引入相关的实战案例,来解决让人头疼的分布式事务问题。 二、tcc-transaction框架介绍 介绍:tcc-...
  • 事务一旦开始,就不能被接口中的任何其他事务(其他master)中断。此类事务就是原子事务(Atomic Transaction)。
  • set autocommit=0 和 start transaction区别 相同之处 set autocommit=0 是显示设置手动提交事务 start transaction 是隐式的设置手动提交事务 不同之处 start transaction To disable autocommit mode ...
  • 注意:在从库上执行备份时,即--dump-slave=2,这时整个dump过程都是stop io_thread的状态 关于mysqldump工作原理 一定要区别对待事务表innodb和非事务表myisam,因为备份流程与此息息相关。 注意:即使到目前为止,...
  • ByteTCC、hmily、tcc-transaction

    千次阅读 2019-07-07 13:38:53
    ByteTCC、hmily、tcc-transaction hmily原理 http://dromara.org/website/zh-cn/docs/hmily/index.html
  • Redis之坑:spring-data-redis中的Redis事务 ...Transaction之坑:Spring中配置Transaction与不配置有何区别 Transaction之坑:分析sql执行结果,主动促使事务rollback 首先 Spring中...
  • https://stackoverflow.com/questions/5409085/what-is-the-difference-between-a-session-and-a-transaction-in-jpa-2-0 and 谷歌翻译: 你去银行存了两张支票,然后取出一小笔钱。 所以你要排队,直到出纳员开门...
  • Spring 之 @Transaction 详解

    千次阅读 多人点赞 2020-05-12 22:23:53
    @Transaction 是 Spring 提供用来控制事务回滚/提交的一个注解,让我们从编程式注解转换到声明式注解。在这里就不做过多的撰述,今天主要来看下 @Transaction 里面的属性使用。 作用域 @Transaction 可以写在类、...
  • 一 Transaction(事务)接口 事务简单的说,就是一组对数据库的操作集合,它们要么全部成功,要么全部失败.这个可以保证数据的一致性,事务具有原子性。 ①Transaction是底层的事务实现中抽象出来的接口。 ②可能是一...
  • 简要地看一下bapi_transaction_commit的代码,我们能很快看出其与commit work的区别。它会在执行commit work之后再调用一个buffer_refresh_all的函数
  • kafka Transaction coordinator

    千次阅读 2017-02-08 22:14:00
    区别在于 Transaction ID 由用户提供,而 PID 是内部的实现对用户透明。 另外,为了保证新的Producer启动后,旧的具有相同 Transaction ID 的Producer即失效,每次Producer通过 Transaction ID 拿到PID的同时,还会...
  • SpringBoot 之 @Transaction注解的类级别和方法级别的区别 @Transactional放在类级别上等同于该类的每个方法都放上了@Transactional 默认将类中的所有函数纳入事务管理. @Transactional(readOnly=true) //配置...
  • Transaction

    2019-02-17 15:21:48
    问题 transactional advice 和AOP有什么关系 基于织入和基于类代理之间的区别 这段话在说事务Bean的寻找范围?
  • java事务实现世界可分为两种 一种是jdbc事务,也叫本地事务,令外一种是JTA事务,也叫全局事务。...javax.transaction.Synchronization 定义了事务完成前后改做的事,使用方式一般是先注册,在适当的时机调javax.trans
  • 可以看到的是 , Letter 的内容通常是 Short Paper, 有即时性的 , 而 Transaction 收录的内 容则没有这个在时间上的特性 . 3 至于 Journal 的內容 , 是属于比较难的 。 Journal 所收录的內容介于 Transaction 及 ...
  • Oracle事务Transaction

    2020-09-18 10:11:09
    事务由事务开始(begin transaction)和事务结束(end transaction)之间执行的全体操作组成。 事务的属性-ACID 原子性(Atomicity)-事务的原子性强调了一个事物是一个逻辑工作单元,是一个整体,是不可分割的。一个...
  • FragmentManager manager = ...FragmentTransaction transaction = manager.beginTransaction(); transaction.add(mContainerId, mFragment); transaction.commit(); 正常情况是commit就提交了。但是
  • REQUIRED和SUPPORTS在外围方法支持事务的时候没有区别,均加入外围方法的事务中; PROPAGATION_MANDATORY 说明:使用当前的事务,如果当前没有事务,就抛出异常。 代码: @Transactional(propagation = Propagation...
  • CALL TRANSACTION: 1、同步或异步处理; 2、可以传输少量的数据; 3、处理速度快; 4、不能生成错误日志; 5、数据自动更新。  如果BDC出错时我们应该如何处理:可以设置“出错时转前台运行/仅显示错误,E...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 103,410
精华内容 41,364
关键字:

transaction区别