时间戳

首页 > 解决方案 > 在一个事务中插入和更新时 Sql server 死锁

java - 在一个事务中插入和更新时 Sql server 死锁

问题描述

我正在使用 Azure SQL + Java + Spring Boot 2。目前我正在尝试了解死锁发生的原因。在事务中，我正在对同一张表但不同的行进行插入和更新。据我了解，SQL Server 默认使用rowlock和read_committed隔离。

这是死锁的详细信息：

<deadlock>
    <victim-list>
        <victimProcess id="process2b8618644e8"/>
    </victim-list>
    <process-list>
        <process id="process2b8618644e8" taskpriority="0" logused="352"
                 waitresource="KEY: 16:72057594043760640 (5f601e0257f1)" waittime="1321" ownerId="9246067"
                 transactionname="implicit_transaction" lasttranstarted="2019-02-17T13:03:49.683" XDES="0x2b868778458"
                 lockMode="U" schedulerid="2" kpid="288932" status="suspended" spid="118" sbid="0" ecid="0" priority="0"
                 trancount="2" lastbatchstarted="2019-02-17T13:03:49.793" lastbatchcompleted="2019-02-17T13:03:49.760"
                 lastattention="1900-01-01T00:00:00.760" clientapp="Microsoft JDBC Driver for SQL Server"
                 hostname="TZ-MacBook-Pro.local" hostpid="0" loginname="master" isolationlevel="read committed (2)"
                 xactid="9246067" currentdb="16" currentdbname="test" lockTimeout="4294967295" clientoption1="671088672"
                 clientoption2="128058">
            <executionStack>
                <frame procname="unknown" queryhash="0x431f2517c2d3feb8" queryplanhash="0x3a793ad664472011" line="1"
                       stmtstart="110" stmtend="238"
                       sqlhandle="0x02000000060c530e608cef3b3e4e4712f48c40d2efd9b04d0000000000000000000000000000000000000000">
                    unknown
                </frame>
                <frame procname="unknown" queryhash="0x0000000000000000" queryplanhash="0x0000000000000000" line="1"
                       sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
                    unknown
                </frame>
            </executionStack>
            <inputbuf>
                (@P0 int,@P1 nvarchar(4000),@P2 nvarchar(4000),@P3 int)update bug set lock=@P0, status=@P1 where
                bug_id=@P2 and lock=@P3
            </inputbuf>
        </process>
        <process id="process2b84f702108" taskpriority="0" logused="700"
                 waitresource="KEY: 16:72057594043760640 (185e9bfc7320)" waittime="1287" ownerId="9246090"
                 transactionname="implicit_transaction" lasttranstarted="2019-02-17T13:03:49.727" XDES="0x2b868764458"
                 lockMode="U" schedulerid="1" kpid="334812" status="suspended" spid="115" sbid="0" ecid="0" priority="0"
                 trancount="2" lastbatchstarted="2019-02-17T13:03:49.830" lastbatchcompleted="2019-02-17T13:03:49.790"
                 lastattention="1900-01-01T00:00:00.790" clientapp="Microsoft JDBC Driver for SQL Server"
                 hostname="TZ-MacBook-Pro.local" hostpid="0" loginname="master" isolationlevel="read committed (2)"
                 xactid="9246090" currentdb="16" currentdbname="test" lockTimeout="4294967295" clientoption1="671088672"
                 clientoption2="128058">
            <executionStack>
                <frame procname="unknown" queryhash="0x431f2517c2d3feb8" queryplanhash="0x3a793ad664472011" line="1"
                       stmtstart="110" stmtend="238"
                       sqlhandle="0x02000000060c530e608cef3b3e4e4712f48c40d2efd9b04d0000000000000000000000000000000000000000">
                    unknown
                </frame>
                <frame procname="unknown" queryhash="0x0000000000000000" queryplanhash="0x0000000000000000" line="1"
                       sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
                    unknown
                </frame>
            </executionStack>
            <inputbuf>
                (@P0 int,@P1 nvarchar(4000),@P2 nvarchar(4000),@P3 int)update bug set lock=@P0, status=@P1 where
                bug_id=@P2 and lock=@P3
            </inputbuf>
        </process>
    </process-list>
    <resource-list>
        <keylock hobtid="72057594043760640" dbid="16" objectname="b51ce3c4-02f0-4dfa-89dd-3ab2f45beac7.dbo.bug"
                 indexname="bug_pk" id="lock2b8658c6f00" mode="X" associatedObjectId="72057594043760640">
            <owner-list>
                <owner id="process2b84f702108" mode="X"/>
            </owner-list>
            <waiter-list>
                <waiter id="process2b8618644e8" mode="U" requestType="wait"/>
            </waiter-list>
        </keylock>
        <keylock hobtid="72057594043760640" dbid="16" objectname="b51ce3c4-02f0-4dfa-89dd-3ab2f45beac7.dbo.bug"
                 indexname="bug_pk" id="lock2b856aa7f80" mode="X" associatedObjectId="72057594043760640">
            <owner-list>
                <owner id="process2b8618644e8" mode="X"/>
            </owner-list>
            <waiter-list>
                <waiter id="process2b84f702108" mode="U" requestType="wait"/>
            </waiter-list>
        </keylock>
    </resource-list>
</deadlock>

此外，我在 id 列上使用了聚集索引，随机操作顺序没有问题。此外，当我只在事务中插入时，一切正常，没有死锁。 如果我切换到 PostgreSql，则不会出现死锁问题。

那么，为什么我在 Azure SQL 中遇到了死锁？

这是Java源代码：

    @Transactional
    public void bug() {
        BugEntity bugEntity = bugRepo.findById("1234")
                .orElseGet(() -> createBugEntity());

        if (bugEntity.getStatus().equals("SomeStatus")) {
            bugEntity.setStatus("NewStatus");
            bugRepo.save(bugEntity);
        }

    }

    private BugEntity createBugEntity() {
        BugEntity bugEntity = BugEntity.builder()
                .bugId(UUID.randomUUID().toString())
                .status("SomeStatus")
                .data("SomeData")
                .build();
        return bugRepo.save(bugEntity);
    }

实体类：

@AllArgsConstructor
@NoArgsConstructor
@Data
@Builder
@Entity(name = "bug")
@DynamicUpdate
public class BugEntity {

    @Id
    String bugId;
    String status;
    String data;

    LocalDateTime dateTime;

    @Version
    int lock;


}

为了重现死锁，我使用带有几个并行请求的加特林模拟。

标签： javaspring-bootazure-sql-databasedeadlock

解决方案

死锁的一个常见原因是需要查询和索引调整的查询触及的数据多于必要的数据。

死锁跟踪显示参数作为nvarchar(4000)数据类型传递。这可能会阻止有效使用列上的索引，varchar因为nvarchar它的数据类型优先级高于varchar. 当从应用程序数据类型推断参数数据类型时，此问题尤其常见，因为字符串通常是 Unicode，例如在 Java 和 .NET 语言中，导致nvarchar参数与基础列数据类型无关。

解决方案是对字符串使用 varchar 参数而不是 nvarchar，除非基础列是nvarchar. 如果您不在nvarchar数据库中使用，请指定 JDBC 连接字符串参数sendStringParametersAsUnicode，如本答案中所述。或者，更改应用程序代码或框架配置以使用列的varchar参数类型varchar。

最佳实践是确保参数与基础数据库列的类型相匹配。这将提高性能和并发性，并且还有其他好处。

推荐阅读