Изучаем Java EE 7 - [101]

Рис. 6.3. Кэш второго уровня

Каждая реализация наделяется своим подходом к кэшированию объектов путем либо разработки собственного механизма, либо повторного использования уже существующих решений (с открытым исходным кодом или коммерческих). Кэширование может быть распределено по кластеру либо нет — все возможно, когда спецификация игнорирует соответствующую тему. Создатели JPA 2.0 признали, что кэш второго уровня необходим, и добавили операции кэширования в стандартный API-интерфейс. Приведенный в листинге 6.33 API-интерфейс крайне минималистичен (поскольку цель JPA не заключается в том, чтобы стандартизировать полнофункциональный кэш), однако позволяет коду выполнять запросы к некоторым сущностям и удалять их из кэша второго уровня стандартным образом. Как и менеджер сущностей, javax.persistence.Cache является интерфейсом, реализуемым системой кэширования поставщика постоянства.

Листинг 6.33. Cache API

public interface Cache {
··// Содержит ли кэш определенную сущность
··public boolean contains(Class cls, Object id);

··// Удаляет сущность из кэша
··public void evict(Class cls, Object id);
··// Удаляет сущности указанного класса (и его подклассы) из кэша
··public void evict(Class cls);
··// Очищает кэш
··public void evictAll();

··// Возвращает реализацию кэша, специфичную для поставщика
··public  T unwrap(Class cls);
}

Вы можете использовать этот API для проверки того, содержится ли определенная сущность в кэше второго уровня, а также для очищения всего кэша. Задействуя этот API, вы можете явным образом проинформировать поставщика постоянства о том, является ли сущность кэшируемой, с помощью аннотации @Cacheable, как показано в листинге 6.34. Если у сущности отсутствует аннотация @Cacheable, то эта сущность и ее состояние не должны кэшироваться поставщиком.

Листинг 6.34. Сущность Customer является кэшируемой

@Entity
@Cacheable(true)
public class Customer {
··@Id @GeneratedValue
··private Long id;
··private String firstName;
··private String lastName;
··private String email;
··// Конструкторы, геттеры, сеттеры
}

Аннотация @Cacheable принимает логическое значение. Как только вы решите, какая сущность должна быть кэшируемой, вам придется проинформировать поставщика о том, какой механизм кэширования следует использовать. Это можно сделать с помощью JPA, указав атрибут shared-cache-mode в файле persistence.xml. Далее приведены возможные значения:

• ALL — будут кэшироваться все сущности, а также связанные с ними состояния и данные;

• DISABLE_SELECTIVE — будут кэшироваться все сущности за исключением тех, что снабжены аннотацией @Cacheable(false);

• ENABLE_SELECTIVE — будут кэшироваться все сущности, снабженные аннотацией @Cacheable(true);

• NONE — кэширование будет отключено для единицы сохраняемости;

• UNSPECIFIED — поведение кэширования будет неопределенным (могут быть применены правила по умолчанию, специфичные для поставщика).

Если не задать ни одно из этих значений, то поставщик будет сам решать, какой механизм кэширования применять. В коде, приведенном в листинге 6.35, показано, как использовать соответствующий механизм кэширования. Сначала мы создаем объект Customer и обеспечиваем его постоянство. Поскольку сущность Customer является кэшируемой (см. листинг 6.34), она должна быть размещена в кэше второго уровня (с помощью метода EntityManagerFactory.getCache(). contains()). Вызов метода ache.evict(Customer.class) удаляет эту сущность из кэша.

Листинг 6.35. Сущность Customer является кэшируемой

Customer customer = new Customer("Патриция", "Джейн", "[email protected]");

tx.begin();
em.persist(customer);
tx.commit();

// Использует EntityManagerFactory для получения Cache
Cache cache = emf.getCache();

// Сущность Customer должна располагаться в кэше
assertTrue(cache.contains(Customer.class, customer.getId()));

// Удаляет сущность Customer из кэша
cache.evict(Customer.class);

// Сущность Customer больше не должна располагаться в кэше
assertFalse(cache.contains(Customer.class, customer.getId()));

Конкурентный доступ

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

Чтобы проиллюстрировать проблему конкурентного доступа к базе данных, обратимся к примеру приложения с двумя конкурирующими потоками, показанными на рис. 6.4. Один поток ищет книгу по ее идентификатору и повышает цену книги на $2. Другой поток делает то же самое, но повышает цену книги на $5. Если вы выполните эти два потока одновременно в отдельных транзакциях, осуществляя манипуляции с одной и той же книгой, то не сможете предсказать окончательную цену книги. В этом примере начальная цена книги составляет $10. В зависимости от того, какая транзакция финиширует последней, цена может повыситься до $12 или 15.