在 SAP 帮助文档里有关于 ABAP lock 支持的全部类型和说明，总共支持四种类型的锁：S, E, X 和 O.
注意 E 锁和 X 锁的区别是，E 锁 可以在同一个事务里多次被请求，但 X 锁即使在同一个事务里，也只能被请求一次。
我在 SAP CRM 系统里看到 One Order 页面点击 Edit 按钮时，背后使用的 Lock Object 实际是 E_CRM_ORDER, 这个 object 的 Lock mode 设置的是 Read Lock 即 Share Lock，共享锁：
但是我在 WebClient UI 上点击了 Edit 按钮后，在 SM12 事务码里，看到的 mode 却是 E：排他锁。
在 SE11 里查看 Enqueue Function Module 名称：ENQUEUE_E_CRM_ORDER
设置断点，运行时单步调试，发现传入的参数是 V：Only conflict check exclusive lock, as with 'E'
mode 参数传入的 V：
在 ABAP 中，Lock 机制被设计为一个独立的服务，它使用一种叫做 Lock Object 的对象来对需要锁定的数据表和字段进行描述。一个 Lock Object 可以包含一个或者多个数据表，这些数据表之间通过外键关系连接在一起。然后，我们可以通过调用特定的函数模块来对这个 Lock Object 进行操作，比如 ENQUEUE_<lock object>（请求设置锁）和 DEQUEUE_<lock object>（请求释放锁）。
在 ABAP Lock 机制中，Conflict Check 是用来检测和处理锁冲突的过程。当一个用户（或者一个事务）试图对一个已经被其他用户锁定的数据进行锁定时，就会发生锁冲突。ABAP Lock 服务在收到锁请求后，会首先检查这个请求的 Lock Mode，然后根据已经存在的锁和请求的 Lock Mode 来决定是否允许这个锁请求。
以一个简单的例子来说明这个过程。假设我们有一个 Lock Object ZLOCKOBJ，它描述了一个数据表 ZTABLE。用户 A 首先通过调用 ENQUEUE_ZLOCKOBJ 来对 ZTABLE 中的某一行数据设置一个 Exclusive Lock，这个请求被成功执行，ZTABLE 中的这一行数据被锁定。然后用户 B 也想对 ZTABLE 中的这一行数据设置一个 Exclusive Lock，他也通过调用 ENQUEUE_ZLOCKOBJ 来发送锁请求。这时，ABAP Lock 服务在进行 Conflict Check 时，会发现 ZTABLE 中的这一行数据已经被用户 A 独占锁定，因此，用户 B 的锁请求会被拒绝，用户 B 会收到一个锁冲突的消息。
ABAP Lock 服务提供了多种 Lock Mode，比如 Exclusive Lock（独占锁），Shared Lock（共享锁）等，这些不同的 Lock Mode 会影响 Conflict Check 的结果。例如，如果用户 A 设置了一个 Shared Lock，那么用户 B 的 Shared Lock 请求就不会被拒绝，因为 Shared Lock 允许多个用户同时读取同一份数据，但是不允许修改。
ABAP Lock 机制的设计和实现使得我们可以在 SAP 系统中更有效地管理和控制并发操作，保证数据的一致性和完整性。同时，ABAP Lock 机制也提供了一套详细的错误处理和恢复机制，让我们可以更好地处理并发操作中可能出现的各种问题和错误。