EJB Singleton - метод Lock READ, вызывающий метод Lock WRITE того же экземпляра - PullRequest
Новая
       13

EJB Singleton - метод Lock READ, вызывающий метод Lock WRITE того же экземпляра

0 голосов
/ 15 ноября 2018

Учитывая синглтон, как этот: 

@Singleton
public class waitingTimeManager {

    private Map<Integer, Object> waitingTimes;

    @PostConstruct
    public void setup() {
        waitingTimes = new HashMap<>();
    }

    @Lock(LockType.READ)
    public boolean shouldWeWait(Integer id) {
        if (waitingTimes.containsKey(id)) {
            boolean wait = someLogic(waitingTimes.get(id));
            if (!wait) {
               // we don't need to wait for it anymore
               stopWaiting(id);
            }
            return wait;
        }
        return false;
    }

    @Lock(LockType.WRITE)
    public void stopWaiting(Integer id){
        waitingTimes.remove(id);
    }

}

Начальный метод shouldWeWait может быть доступен одновременно нескольким потокам. Другой stopWaiting должен будет получить блокировку записи.

Будет ли звонок на stopWaiting внутри долженWeWait попытаться получить блокировку WRITE? или просто выполнить его, так как он уже получил блокировку READ?

1 Ответ

0 голосов
/ 15 ноября 2018

Нет, он не будет пытаться получить блокировку записи.

Работа с контейнером выполняется внутри перехватчиков, оборачивая вызовы EJB-методов. Например, когда BeanA без состояния вызывает ваш синглтон - он делает это через прокси, что делает возможными гарантии, предоставляемые контейнером (получение блокировки и т. Д.).

Но в данном случае это просто обычный вызов метода (stopWaiting), не заключенный в прокси, поэтому нет места для магии.

...