분산락 관리에 대한 정리

분산락을 처음 적용할때 각 키별로 락을 걸어도 나는 순차적으로 처리를 할 줄 알았다.

즉 lock name 이 a, b 가 있으면 a 해제후 b 가 처리되는줄 알았으나

여러번 테스트를 통해 정리하니 각 lock name 에 대해 락을 거는거지 락 네임이 다르면 다른 락으로 간주하고 동시에 진행이 되는것이었다.

그래서 lock name을 잘지정해야 할 것 같다.

2023-08-10T13:45:50.995+09:00  INFO 26338 --- [ol-4-thread-149] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-
Hibernate: 
    select
        s1_0.id,
        s1_0.count,
        s1_0.created_date,
        s1_0.updated_date 
    from
        seat_count s1_0 
    where
        s1_0.id=?
user 149 seat 100 currentSeatCount = 0
Hibernate: 
    select
        r1_0.id,
        r1_0.created_date,
        r1_0.reservation_status,
        r1_0.seat,
        r1_0.updated_date,
        u1_0.id,
        u1_0.created_date,
        u1_0.email,
        u1_0.name,
        u1_0.password,
        u1_0.updated_date,
        r1_0.work_type 
    from
        reservation r1_0 
    left join
        users u1_0 
            on u1_0.id=r1_0.user_id 
    where
        r1_0.reservation_status=? 
        and r1_0.created_date between ? and ? 
        and r1_0.user_id=?
Hibernate: 
    select
        r1_0.id,
        r1_0.created_date,
        r1_0.reservation_status,
        r1_0.seat,
        r1_0.updated_date,
        u1_0.id,
        u1_0.created_date,
        u1_0.email,
        u1_0.name,
        u1_0.password,
        u1_0.updated_date,
        r1_0.work_type 
    from
        reservation r1_0 
    left join
        users u1_0 
            on u1_0.id=r1_0.user_id 
    where
        r1_0.reservation_status=? 
        and r1_0.user_id=? 
        and r1_0.created_date between ? and ? 
        and r1_0.seat=? fetch first ? rows only
Hibernate: 
    select
        r1_0.id,
        r1_0.created_date,
        r1_0.reservation_status,
        r1_0.seat,
        r1_0.updated_date,
        u1_0.id,
        u1_0.created_date,
        u1_0.email,
        u1_0.name,
        u1_0.password,
        u1_0.updated_date,
        r1_0.work_type 
    from
        reservation r1_0 
    left join
        users u1_0 
            on u1_0.id=r1_0.user_id 
    where
        r1_0.reservation_status=? 
        and r1_0.created_date between ? and ? 
        and r1_0.seat=? fetch first ? rows only
Hibernate: 
    insert 
    into
        reservation
        (id, created_date, reservation_status, seat, updated_date, user_id, work_type) 
    values
        (default, ?, ?, ?, ?, ?, ?)
Hibernate: 
    select
        s1_0.id,
        s1_0.count,
        s1_0.created_date,
        s1_0.updated_date 
    from
        seat_count s1_0 
    where
        s1_0.id=?
Hibernate: 
    select
        s1_0.id,
        s1_0.count,
        s1_0.created_date,
        s1_0.updated_date 
    from
        seat_count s1_0 
    where
        s1_0.id=?
currentSeatCount = 1
Hibernate: 
    insert 
    into
        seat_count
        (count, created_date, updated_date, id) 
    values
        (?, ?, ?, ?)
2023-08-10T13:45:51.245+09:00  INFO 26338 --- [ol-4-thread-148] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-
Hibernate: 
    select
        s1_0.id,
        s1_0.count,
        s1_0.created_date,
        s1_0.updated_date 
    from
        seat_count s1_0 
    where
        s1_0.id=?
user 148 seat 100 currentSeatCount = 1

실제로 해당 로그를 보면 lock name이 같기 때문에 모든 트랜잭션이 끝난후 진행을 한다. 하지만 lock name을 다르게 한다면?

2023-08-10T13:58:27.862+09:00  INFO 26612 --- [ool-4-thread-19] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-19
2023-08-10T13:58:27.862+09:00  INFO 26612 --- [ool-4-thread-62] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-62
2023-08-10T13:58:27.862+09:00  INFO 26612 --- [ool-4-thread-72] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-72
2023-08-10T13:58:27.862+09:00  INFO 26612 --- [ool-4-thread-81] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-81
2023-08-10T13:58:27.862+09:00  INFO 26612 --- [ool-4-thread-37] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-37
2023-08-10T13:58:27.863+09:00  INFO 26612 --- [ool-4-thread-38] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-38
2023-08-10T13:58:27.862+09:00  INFO 26612 --- [ool-4-thread-79] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-79
2023-08-10T13:58:27.863+09:00  INFO 26612 --- [pool-4-thread-1] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-1
2023-08-10T13:58:27.863+09:00  INFO 26612 --- [ool-4-thread-69] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-69
2023-08-10T13:58:27.863+09:00  INFO 26612 --- [ool-4-thread-29] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-29
2023-08-10T13:58:27.863+09:00  INFO 26612 --- [ool-4-thread-50] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-50
2023-08-10T13:58:27.864+09:00  INFO 26612 --- [ool-4-thread-21] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-21
2023-08-10T13:58:27.864+09:00  INFO 26612 --- [ool-4-thread-15] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-15
2023-08-10T13:58:27.864+09:00  INFO 26612 --- [ool-4-thread-41] c.l.health.core.aop.DistributedLockAop   : get lock hazelcast-41

lock name이 다르기때문에 각각 다른 lock으로 관리된다.

즉 공통의 자원에 대한 키 관리를 잘해야 해당 문제를 잘 해결할 수 있을것 같다.