2010-02-17 3 views
1

일부 느슨하게 결합 된 구성 요소가 JMS를 통해 메시지를 교환하여 통신하는 시스템이 있습니다. 이제는 두 개 이상의 구성 요소가 동시에 액세스 할 수 없도록 보호해야하는 공유 리소스로 이어지는 새로운 요구 사항을 검토 중입니다. 시스템에 너무 많은 추가 복잡성을 추가하지 않고 공유 리소스에 대한 액세스를 조정하는 방법을 찾고 있습니다. 예를 들어, 필요하지 않으면 전용 분산 잠금 관리자를 혼합에 추가하고 싶지 않을 것입니다.JMS를 분산 형 잠금 관리자로 사용 하시겠습니까?

저는 JMS 인프라를 기반으로하는 부분적인 해결책을 가지고 있습니다. 기본적으로 대기열에 잠금 메시지를 보냅니다. 작성자 대기열에 메시지가있는 경우 메시지를 보낸 구성 요소가 메시지를 다시 제거 할 때까지 아무도 그 대기열에 게시 할 수 없습니다. 마찬가지로, 독자가 리소스를 읽기 시작할 때 독자 큐에 메시지를 보내고 완료되면 메시지를 제거합니다. 작성자는 독자와 작성자가 모두 대기열에 놓일 때까지 작성을 시작하지 않습니다. 독자는 빈 라이터 대기열을 볼 때까지 시작하지 않습니다. 작가는 작가 큐에 게시하지 않도록 물론

, 나는 모두 큐에 대한 액세스를 동기화하는 방법을 찾을 필요가있는 동안 이미 빈 작가 큐를 본 독자 큐에 대한 독자의 게시물 ..

합리적인 금액으로 그러한 것을 가져갈 수 있습니까? 기존 JMS 구현에 잠금 관리자가 구현되어있을 수 있습니까? 당신이 추천하는 화제에 대한 논문이 있습니까?

답변

2

매우 문제가있는 것 같습니다. 너무 많은 엣지 케이스. 너무 많은 함정 (예 : 구성 요소가 충돌하여 잠금을 제거하지 못하면 어떻게됩니까?) 너무 많이 잠금 장치를 사용하지 마십시오. 물론 분산 잠금 장치를 사용하지 마십시오. JMS 서버의 기능을 사용하여 트랜잭션을 사용하여 필요한 것을 달성하고 잊어 버리십시오.

1

아니요 대신 Hazelcast distributed locks을 확인하시기 바랍니다.

Hazelcast는 Java 용 map, multimap, queue, topic, lock 및 executor 서비스의 트랜잭션 방식의 분산 된 구현입니다.