Распределенная блокировка и Java EE - PullRequest
Новая
       22

Распределенная блокировка и Java EE

4 голосов
/ 28 марта 2011

Я пишу приложение Java EE с использованием JBoss AS 6, и у меня есть ресурс, который требует эксклюзивного доступа (некоторый интерфейс к стороннему программному обеспечению) к методу для данного параметра. В настоящее время я капризничаю (поскольку спецификация запрещает это ) и использую java.util.concurrent.ReentrantLock для обработки блокировки.

Теперь я объединяю несколько серверов приложений JBoss вместе, поэтому мне нужно решение, которое работает на разных узлах кластера. Я думаю, что у меня есть по крайней мере следующие варианты.

  1. Общий кэш (Infinispan)
  2. JGroups
  3. Блокировка на основе файловой системы (вероятно, плохая, но мы все равно полагаемся на общую файловую систему)
  4. База данных
  5. Синглтон EJB ?

В идеале, я ищу API высокого уровня, чтобы я мог писать EJB-методы, подобные этому 

public class MyEJBBean {

    private SharedLock lock;

    public void doSomethingWithSharedResource(String s) {
        lock.lock(); // blocks until shared resource is not used by anyone else
        try {
           // Use shared resource
        } 
        finally {
           lock.unlock();
        }
    }

Я что-то пропустил? У кого-нибудь есть опыт работы с этим механизмом блокировки, которым они могут поделиться?

Ответы [ 2 ]

2 голосов
/ 28 марта 2011

Как насчет использования http://hadoop.apache.org/zookeeper/?Это своего рода очень легкая файловая система в распределенных системах и хорошее решение для реализации блокировки.

См. Это: http://hadoop.apache.org/zookeeper/docs/r3.1.2/recipes.html#sc_outOfTheBox

2 голосов
/ 28 марта 2011

В идеале я бы предложил обернуть стороннее программное обеспечение в отдельное приложение, работающее только на одном экземпляре. Таким образом, вы можете обрабатывать блокировку с помощью синглетонов EJB (я думаю, @Singleton не поможет вам в вашем сценарии) и выставлять ее с помощью удаленного EJB / WS. Похоже, что это программное обеспечение немного неприятно (однопоточное?), Поэтому дополнительное удобство интерфейса EJB будет дополнительным преимуществом.

Подумайте об этом - если вы можете получить доступ к библиотеке только один раз для всей системы, зачем ее распространять? Всегда можно использовать не более одного экземпляра.

Если вы хотите придерживаться однородной распределенной системы (что в целом неплохая идея), я бы предложил блокировку базы данных, используя SELECT FOR UPDATE. Я никогда не пробовал, но я думаю, что выдача такого SQL-кода перед использованием вашей библиотеки (получение блокировки) и разрешение контейнеру EJB совершать транзакцию (эффективно снимая блокировку) впоследствии сделают свое дело.

...