Добрый день, Хабражитель!

Уверен с форматом nine-patch уже все давным-давно знакомы, вероятно даже не раз пользовались им в своих Android-проектах (а может даже и где-то ещё). Также о нём чуть менее года назад skkap писал небольшую статью о том, что это за формат, и «с чем его едят». Также он описал инструмент, предлагаемый для быстрого редактирования этих самых файлов.

Собственно, прошёл уже почти год с того момента и я, опять наткнувшись на ту статью и вспомнив жалобы знакомых на неудобство этого самого «инструмента», решил посмотреть нет ли каких других вариантов и, к моему большому удивлению, я таковых не нашёл. Вероятно потому, что формат сам из себя ничего сложного и специфичного не представляет (при желании nine-patch файлы можно редактировать почти в любом графическом редакторе поддерживающем png) и тем более уже есть готовый инструмент (пусть и не самый удобный).

Тут я и решил лично взяться за дело…

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

Миграционные скрипты

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

1. Рестарт сервера — самый простой и, обычно, самый не приемлемый способ;
2. Очистка кеша через определенные механизмы — пожалуй самый оптимальный по простоте и надежности метод. Этот метод можно вынести, например в JMX, на веб страничку или другой интерфейс и вызывать при необходимости. Гибкость метода в том, что пишется это один раз, а используется сколько угодно и где угодно. В случае, если Ваш провайдер кеша — EHCache и класс провайдер — SingletonEhCacheProvider, то Ваш код может выглядеть так:
   

   public String dumpKeys() {
       String regions[] = CacheManager.getInstance().getCacheNames();
       StringBuilder allkeys = new StringBuilder();
       String newLine = System.getProperty("line.separator");
       for (String region : regions) {
           Ehcache cache = CacheManager.getInstance().getEhcache(region);
           allkeys.append(toSomeReadableString(cache.getKeys()));
           allkeys.append(newLine);
       }
       return allkeys.toString();
   }
   

   
   Естественно что этот код должен выполняться в том же процессе что и хибернейт, статистику которого Вы хотите отследить. Подробней можно прочитать тут. Того же можно добиться используя фабрику сессий.
   
3. Запуск миграционных скриптов, используя фабрику сессий работающего сервера. Это похоже на второй метод, с той лишь разницей, что мы не очищаем кеш, а пропускаем все миграционные скрипты через существующую фабрику. Таким образом все необходимые кеши обновляться сами. Этот метод рационально использовать в случае если кеш большой и дешевле его обновлять нежели создавать по новой;

Довольно часто в java приложениях с целью снижения нагрузки на БД используют кеш. Не много людей реально понимают как работает кеш под капотом, добавить просто аннотацию не всегда достаточно, нужно понимать как работает система. Поэтому этой статье я попытаюсь раскрыть тему про то, как работает кеш популярного ORM фреймворка. Итак, для начала немного теории.

Прежде всего Hibernate cache — это 3 уровня кеширования:

• Кеш первого уровня (First-level cache);
• Кеш второго уровня (Second-level cache);
• Кеш запросов (Query cache);

Кеш первого уровня

Кеш первого уровня всегда привязан к объекту сессии. Hibernate всегда по умолчанию использует этот кеш и его нельзя отключить. Давайте сразу рассмотрим следующий код:

SharedDoc persistedDoc = (SharedDoc) session.load(SharedDoc.class, docId);
System.out.println(persistedDoc.getName());
user1.setDoc(persistedDoc);

persistedDoc = (SharedDoc) session.load(SharedDoc.class, docId);
System.out.println(persistedDoc.getName());
user2.setDoc(persistedDoc);

Возможно, Вы ожидаете, что будет выполнено 2 запроса в БД? Это не так. В этом примере будет выполнен 1 запрос в базу, несмотря на то, что делается 2 вызова load(), так как эти вызовы происходят в контексте одной сессии. Во время второй попытки загрузить план с тем же идентификатором будет использован кеш сессии.
Один важный момент — при использовании метода load() Hibernate не выгружает из БД данные до тех пор пока они не потребуются. Иными словами — в момент, когда осуществляется первый вызов load, мы получаем прокси объект или сами данные в случае, если данные уже были в кеше сессии. Поэтому в коде присутствует getName() чтобы 100% вытянуть данные из БД. Тут также открывается прекрасная возможность для потенциальной оптимизации. В случае прокси объекта мы можем связать два объекта не делая запрос в базу, в отличии от метода get(). При использовании методов save(), update(), saveOrUpdate(), load(), get(), list(), iterate(), scroll() всегда будет задействован кеш первого уровня. Собственно, тут нечего больше добавить.