JEE6 @ApplicationScoped bean и параллелизм

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

Я думаю использовать @ApplicationScoped bean с AtomicInteger , как это

@ApplicationScoped
class VisitsCounter {

    private AtomicInteger counter;

    @PostConstruct
    public void construct() {
        counter = new AtomicInteger(0);
    }

    public int visited() {
        return counter.incrementAndGet();
    }
}

Мой вопрос: хорошо ли при одновременном рассмотрении нескольких запросов? Или мне нужно играть с аннотациями @ConcurrencyManagement и @Lock ? Я полагаю, что Atomic * должен делать трюк, но я не уверен.

Также делает то же самое, когда у меня есть потокобезопасные коллекции как поля? Например. скажем, у меня есть

@ApplicationScoped
class ValuesHolder {

    private List values;

    @PostConstruct
    public void construct() {
        values = Collections.synchronizedList(new LinkedList());
    }

    public void insert(String value) {
        values.add(value);
    }

    public String remove(String value) {
        return values.remove(value);
    }
}

действительно ли операции потокобезопасны?

Говорят, что аннотации и блокировки параллелизма должны использоваться при изменении состояния компонента, но что, если мой список уже заботится о безопасности потоков?

20
добавлено
Просмотры: 2
nl ja de
Как реализовано, я не вижу проблем с параллелизмом.
добавлено автор McDowell, источник

1 ответы

В CDI у вас нет управления параллелизмом, поэтому @ApplicationScoped просто указывает мощность введенного объекта (т. Е. Инструктирует движок инъекции создать только один экземпляр вашего компонента и использовать его во всех приложениях) , Он не преобразует ваш компонент в EJB и не требует принудительного ограничения.

Таким образом, хотя операции в примерах по сути являются потокобезопасными, благодаря AtomicInteger и синхронизированному списку, в общем случае это не так.

В общем вы можете:

  • вручную синхронизировать доступ к списку через стандартные примитивы параллелизма (как вы это сделали)

  • или используйте аннотацию javax.ejb.Singleton , которая указывает серверу приложений управлять параллелизмом. Это преобразует ваш компонент в EJB и по умолчанию обеспечивает @ConcurrencyManagement (ConcurrencyManagementType.CONTAINER) и @Lock (LockType.WRITE) .

Кстати, @ConcurrencyManagement и @Lock доступны только для одноэлементных сессионных компонентов.

33
добавлено
Неплохо. Я думал, что произойдет, если я добавлю bean-код @ApplicationScoped в EJB @Stateful , похоже, что вы можете столкнуться с проблемами, поскольку из двух экземпляров EJB вы могут изменять одни и те же данные.
добавлено автор dalvarezmartinez1, источник
Являются ли поля ( counter , values ​​) гарантированно видимыми? В конце концов, к ним обращаются разные потоки без каких-либо механизмов параллелизма.
добавлено автор Frank Neblung, источник