Условный метод блокировки EAN-объекта без состояния

Question

Метод E-D без учета состояния должен выполнять операцию чтения и вставки в транзакции. Первый шаг - сложная проверка, чтобы проверить, разрешена ли операция вставки с заданными параметрами.

public boolean DoCheckThanCreateAndAddItemToGroup(Item newItem, Group group) { 
    // STEP 1: checks if newItem can be created and added to group 
    // This is a complex operation with database reading and some logic 
    // using the current items of the group 
    if (!DoesNewItemFitInGroup(newItem, group)) { 
     return false; 
    } 

    // STEP 2: creates (persists) Item and adds it to Group 
    em.persist(newItem); 
    newItem.setGroup(group); 
    return true; 
} 

Очевидно, что весь метод должен быть заблокирован, чтобы предотвратить одновременное выполнение, чтобы не добавить два или более элементов, которые не помещаются вместе в группе. Обработка транзакций JTA по умолчанию не обеспечивает этого. Метод может выполняться параллельно с той же группой.

В настоящее время при параллельном запуске оба клиента могут пройти проверку до того, как любой из них выполнит операцию вставки, поэтому оба клиента вставляют свой новый элемент. Но эти элементы не подходят друг другу в группе: после того, как один добавлен, другой должен пропустить проверку и не должен быть добавлен.

Даже если я могу установить изоляцию транзакций на уровень SERIALIZABLE (но я не знаю, как это сделать), это не будет идеальным решением, потому что, когда метод работает одновременно с разными группами, блокировка бесполезна и замедляется вниз по системе без необходимости.

Другим решением было бы поместить метод в одноэлементный EJB с помощью @Lock (LockType.WRITE). Но проблема одна и та же: для разных блокировок групп нет необходимости.

Нечто подобное было бы решить эту проблему:

public boolean DoCheckThanCreateAndAddItemToGroup(Item newItem, Group group) { 
    lock(group) { 
     // STEP 1 

     // STEP 2 
    } 
} 

Как добиться такого поведения подходящим образом в среде EJB? (Возможно, в распределенной среде.)

Или любая другая идея, как правильно справиться с этой проблемой?

Answer 1

Как-то я хотел заблокировать метод с помощью группового объекта. Решение основано на идее Andrei, но мне не пришлось изменять объект Group. Я просто должен был добавить эти строки в начале безгосударственного метода сессионного компонента:

Group lockGroup = em.find(Group.class, group.getId()); 
em.lock(lockGroup, LockModeType.PESSIMISTIC_WRITE); 

Пессимистический замок на объекте объекта гарантирует, что если клиент уже заперт тот же объект сущности, второй клиент ждет в эм. блокировки, пока первый клиент не совершит всю транзакцию.

Спасибо, Андрей!