java - 使用 Spring、MyBatis 和 OracleDB 与多个应用程序服务器进行 Java 数据库事务

Question

我在使用多个应用程序服务器使用 Java 执行数据库事务时遇到问题。

场景:

有两个表。 LOCKED_FILE_INFO 和 FILE_INFO

1:FILE_INFO表包含FILEID(Primary)、FILENAME、USERID、FILETYPE、QTY等文件的信息

2: LOCKED_FILE_INFO 表包含 FILEID(Primary)、FILENAME 和 TimeOfLock 等信息

3:多个用户可以在FILE_INFO和LOCKED_FILE_INFO表中输入文件列表或单个文件。

4:在 FILE_INFO 中输入条目之前，我们会在 LOCKED_FILE_INFO 中锁定该特定文件，以便只有 1 个用户可以锁定该 FILE 信息，然后进入 FILE_INFO 表。

5:如果多个用户对同一个文件执行输入，他们将得到 - “信息已被另一个用户锁定”。

逻辑:

a:在 FILE_INFO 表中输入条目之前，我们将检查 LOCKED_FILE_INFO 表以验证文件(例如:file100)是否已存在

b:如果文件已存在(已锁定)- 显示 -“信息已被其他用户锁定”。

c:如果文件不存在(NOT LOCKED)，则在 LOCK_FILE_INFO 表中创建一个条目，这样其他用户就无法锁定该文件，只有成功的用户才能进入 FILE_INFO 表。

d:进入 FILE_INFO 表后，从 LOCKED_FILE_INFO 表中删除锁定文件

问题:

当多个用户尝试在 LOCK_FILE_INFO 中同时锁定同一文件时，我会收到 PRIMARY_KEY 违规异常 当我运行单个应用程序服务器时，不会发生这种情况。仅当多个应用程序服务器正在运行(至少 5 个)时才会发生这种情况

我尝试过的方法很少 a:使用同步 b:使用事务级隔离

但是，当多个用户尝试同时插入 LOCKED_FILE_INFO 表时，我仍然无法锁定特定文件。但是，如果延迟至少 1 秒，那么我根本不会遇到问题。

如有任何建议，我们将不胜感激。谢谢!

Answer 1

出现这个问题是因为有一个 race condition在逻辑中。也就是说，由不同用户进行的两个并发事务可能会成功执行步骤a中的检查，并尝试插入LOCK_FILE_INFO。显然只有一个成功，第二个就会失败。

当并行度发生变化时(当并发运行的进程数量发生变化时)，正在运行的进程中发生的各个事件的时间也会发生变化。因此此类并发场景的行为可能会有所不同。

您有多种选择来解决您遇到的问题。

处理主键违规

您可以捕获异常并显示文件已被锁定的消息。在这种情况下，检查锁定记录是否存在是没有意义的。也就是说您不需要执行步骤a。只需插入一条锁记录，如果存在主键违规 - 锁已经存在。

锁定更新

使用插入锁定的问题是检测冲突的唯一原因是通过约束违规。如果您更改锁定策略以便更新记录。

首先，当创建 FILE_INFO 中的记录时，始终在 LOCK_FILE_INFO 中为文件创建一条记录，或者在 FILE_INFO 表中存储有关锁定的信息(timeOfLock 列应该足够，如果它是 NULL 文件未锁定)。

当需要加锁时，只需执行更新查询即可

update LOCK_FILE_INFO
set TimeOfLock = now()
where TimeOfLock is NULL
   AND FILEID = some_id

然后您需要检查记录是否已更新。每个修改语句都会返回更新记录的数量。要获取此数字，只需从 mybatis 映射器中的插入方法返回 int 即可。如果记录被更新则该事务成功获得锁，否则无法获得文件锁(要么已经被锁定，要么文件已被删除，见下文)。

请注意，这依赖于 some_id 是正确的文件 ID 的事实。可能会发生文件在执行更新语句之前被删除的情况。在这种情况下，文件看起来像是被锁定，但实际上它已经消失了。实际上，这不是问题，因为锁定失败后，您通常需要刷新 UI 以显示文件的更新状态，在这种情况下，您会检测到该文件已消失。

不起作用的选项

通过synchronized进行同步

使用synchronized关键字进行同步(如果正确完成)仅对单进程情况有帮助，因为在这种情况下，同步是使用进程内部的锁完成的。如果有多个 JVM 进程，每个进程都有自己的锁，同步将无法按预期进行。

序列化隔离级别

序列化隔离级别在这种情况下不起作用，因为它无法帮助插入。如果您在两个事务中插入具有相同键的两条记录，则无论隔离级别如何，您都会遇到相同的主键违规。