Главная » Spring » Декларативное  кеширование с помощью аннотаций Spring

0

Помимо возможности настройки кеширования в конфигурацион- ном XML-файле, описанной в предыдущем разделе, модуль Spring Modules поддерживает декларативное кеширование с использовани- ем метаданных на уровне программного кода. Эта поддержка до- ступна в двух вариантах:

# аннотации Java 5 – идеальное решение, если целевой платфор-

мой для приложения является Java 5;

#  Jakarta Commons Attributes – если целевой платформой явля- ются версии Java, предшествующие версии Java 5.

Целевой платформой для приложения RoadRantz является Java 5. Поэтому для настройки кеширования в слое доступа данных будут использоваться аннотации Java 5. Модуль Spring Modules предусмат- ривает две аннотации, имеющие отношение к кешированию:

# @Cacheable – отмечает метод, возвращаемое значение которого

должно кешироваться;

# @CacheFlush – отмечает метод, вызов которого приводит к очист- ке кеша.

С помощью аннотации @Cacheable можно обеспечить кеширование метода getRantsForDay(), как показано ниже:

@Cacheable(modelId="rantzCacheModel")

public  List<Rant>  getRantsForDay(Date  day)  {

return  getHibernateTemplate().find("from  "  +  RANT  + "  where  postedDate  =  ?",  day);

}

Атрибут modelId определяет модель кеширования значений, воз- вращаемых методом getRantsForDay(). Подробнее о том, как определя- ется модель кеширования, будет рассказано чуть ниже. Но сначала, с помощью аннотации @CacheFlush, определим операцию очистки ке- ша, которая будет выполняться при вызове метода saveRant():

@CacheFlush(modelId="rantzFlushModel") public  void  saveRant(Rant  rant)  {

getHibernateTemplate().saveOrUpdate(rant);

}

Атрибут modelId определяет модель очистки кеша, которая будет выполняться при вызове метода saveRant().

Что касается моделей кеширования и очистки кеша, вы, вероятно, хотели бы знать, как они определяются. Элемент <ehcache:annotations> используется для включения поддержки аннотаций кеширования в модуле Spring Modules. В файле roadrantzcache.xml он объявлен, как показано ниже:

<ehcache:annotations>

<ehcache:caching id="rantzCacheModel" cacheName="rantzCache"  />

</ehcache:annotations>

Внутри элемента <ehcache:annotations> необходимо определить хо- тя бы один элемент <ehcache:caching>. Он определяет модель кеши- рования. Проще говоря, модель кеширования – это чуть больше, чем ссылка на именованный кеш, настроенный в файле ehcache.xml. В примере выше мы связали имя rantzCacheModel с именованным ке- шем rantzCache. Соответственно, все аннотации @Cacheable с атрибу- том modelId, имеющим значение rantzCacheModel, будут нацелены на кеш с именем rantzCache.

Определение модели очистки кеша близко напоминает опреде- ление модели кеширования, за исключением того, что ссылается на очищаемый кеш. Определим модель очистки с именем rantzFlushModel рядом с определением модели кеширования rantzCacheModel, восполь- зовавшись элементом <ehcache:flushing>:

<ehcache:annotations>

<ehcache:caching id="rantzCacheModel" cacheName="rantzCache"  />

<ehcache:flushing   id="rantzFlushModel" cacheName="rantzCache"  />

</ehcache:annotations>

Единственное отличие модели очистки кеша от модели кеширо- вания состоит в том, что модель очистки кеша определяет не только кеш, который будет очищаться, но и когда он будет очищаться. По умолчанию очистка кеша будет выполняться после вызова метода, отмеченного аннотацией @CacheFlush. Однако имеется возможность определить другой момент очистки, указав соответствующее значе- ние в атрибуте when элемента <ehcache:flushing>:

<ehcache:annotations>

<ehcache:caching id="rantzCacheModel" cacheName="rantzCache"  />

<ehcache:flushing   id="rantzFlushModel" cacheName="rantzCache"  when="before" />

</ehcache:annotations>

Значение before в атрибуте when говорит о том, что кеш будет очи- щаться перед вызовом метода, отмеченного аннотацией @CacheFlush.

В заключение

Данные – это кровь, текущая по жилам приложения. Некоторые из нас могут даже утверждать, что данные – это и есть приложе- ние. При такой высокой значимости данных очень важно обеспечить надежность, простоту и ясность части приложения, отвечающей за доступ к данным.

Поддержка JDBC и фреймворков ORM принимает на себя основ- ную тяжесть реализации доступа к данным, устраняя необходимость писать шаблонный код, присутствующий во всех механизмах хране- ния данных, и давая нам возможность сосредоточиться на особенно- стях доступа к данным, характерным для конкретного приложения.

Одним из примеров такого упрощения доступа к данным с ис- пользованием Spring является автоматическое управление жизнен- ным циклом соединений с базами данных и сеансов в фреймворках ORM, гарантирующее своевременное их открытие и закрытие. При таком подходе управление механизмами хранения данных становит- ся практически прозрачным для прикладного кода.

В заключение

295

Кроме того, фреймворк Spring может перехватывать исключения, специфические для используемых фреймворков (некоторые из ко- торых могут быть контролируемыми), и преобразовывать в неконт- ролируемые исключения, универсальные для всех фреймворков, реализующих хранение данных, поддерживаемых фреймворком Spring. В их число входит обобщенное исключение SQLExceptions, возбуждаемое механизмом JDBC, которое преобразуется в более осмысленные исключения, описывающие фактическую проблему, приведшую к исключению.

В этой главе было показано, как создать слой доступа к храни- лищу данных в приложениях на основе Spring с использованием JDBC, Hibernate и JPA. Выбор того или иного механизма в значи- тельной степени зависит от личных предпочтений, но, поскольку слой доступа к данным реализуется на основе распространенных ин- терфейсов Java, остальная часть приложения остается независимой от используемого механизма и типа базы данных.

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

 

Источник:   Уоллс К., Spring в действии. – М.: ДМК Пресс, 2013. – 752 с.: ил.

По теме:

  • Комментарии