事务性/一致性的个人理解

(这篇多是个人的一些理解,没有去查找太多的资料,有错误的地方请轻拍.)

自己的代码都是野路子,公司对代码规范要求不高,当初碰到过几个跟一致性相关的问题,总是迷迷糊糊的,反正改改能用就pass了,最近有空,自己总结一下.

关于SAP LUW 和 DB LUW:

从对话过程(dialog step)说起吧,通常认为请求从前台传到AS上处理再把结果返回前台的过程

在AS上,调度机制会给请求分配工作过程,工作过程有自己的和数据库通信的通道,当work process处理结束后

通过自己的通道提交此次的数据更改,然后work process 就空闲等待分配给其他请求,这次对数据库的操作都放在一个DB LUW中

当一个DB LUW结束后,roll back是无效的.

这个DB LUW都是隐式触发的,是在数据库级别的一致性控制.

触发的条件如下:

(1) When the system displays an SAP Screen

(2) When the system sends a dialog message(Okay: E,S, I; No:A,X)

(3) Whenever there are synchronous and asynchronous RFC calls

(4) With call transaction <tcode> or SUBMIT <program> statement

显然,每次请求,都提交数据在特定环境下是不合理的,

例如导入数据,可能产生多个DB LUW,但是有一个失败我就需要回滚

按照这样的机制,先前写入的数据时无法回滚的

于是就有了SAP LUW的概念,简单的说就是从开启SAP LUW的点开始,DB LUW中的操作都会放到一个队列里

而不是立即更新,需要我们手动commit work.

关于数据更新的方式:

1.异步的 commit work : 当前程序把更新任务放到专门的更新数据库的工作过程中,不管结果如何,继续往下执行

2.同步的 commit and wait: 等待数据更新完成后,再往下执行

据说同步中还有两种方式:

a.一个是等待另一个更新程序执行结束

b.利用本程序的'资源'处理更新,操作完成后才往下执行其他内容

异步的提交显然效率高

但是在部分情况下可能导致数据的差异

还没回写到数据库,下一步可能去读取写入的数据,然后造成错误的数据

所以这时候使用同步比较好

关于使用BAPI调用时出现一致性问题:

在部分BAPI的调用中

我们明明在调用结束后 指明了commit work and wait

但是还是出现了数据没有回写的原因

这是由于bapi内部也有一个数据更新机制

而且是异步的

外部调用 如果不对bapi的数据提交方式做限制

默认异步提交,即commit work

然后在bapi调用结束后 commit work and wait

这里就有两次提交,第一次是真正想提交的(默认异步方式)

第二次本意是同步的,但是没有什么有价值的操作了

所以导致了数据不一致,commit work and wait并没有达到同步控制的目的

解决方案一:

一个wait up to '0.5' seconds

人为的等待前一个异步提交操作完成

但是这个时间是不好控制的,只有根据具体应用来估计一个时间

解决方案二:

限制bapi中的数据不提交

而是在bapi调用结束后,手动commit work and wait

或者在bapi中设置为同步的数据提交方式

这也是我们想要的

(但是似乎并不是每个BAPI都提供控制提交方式的参数,好些时候还是使用wait up的操作来保证一致性)