Советы и ошибки в Spring Transactional

В этом посте я соберу самые лучшие практики использования Spring Transactional

Service или DAO?

  • Устанавливайте аннотацию @Transactional в слое сервиса (Service layer), а не в слое DAO. Сервисные бины могут использовать несколько DAO, соблюдая ACID под одной и той же транзакцией. Иначе если только в DAO определен механизм транзакций, то сервисные бины увеличат расходы на создание множественных транзакций для концептуально сгруппированных операций, не говоря уже о неконсистентном состоянии данных, которое мы рискуем получить.

Подробнее

Введение в key-value NoSQL БД Aerospike

Aerospike

Aerospike — это хранилище пар вида ключ-значение с моделью данных без использования схемы. Данные организованы в контейнеры с собственными политиками, называемыми «namespaces» (пространства имен), семантически близкими к понятию «databases» (базы данных) в реляционных БД. В переделах namespace, данные разделены на «sets» (наборы — схоже с таблицей в RDMS) и «records» (записи — схоже со строками в таблице). Каждая запись имеет индексный «key» который уникален в наборе, и один или более именованных «bins» (схоже с колонками), которые содержат значения, ассоциированные с record.

Концепция Aerospike в терминах MySQL

Aerospike MySQL
namespace db
set table
bin column
key primary key
record row
 Рассмотрим далее как установить и сконфигурировать Aerospike, а так же как использовать Java клиент.

Подробнее

Создание рекомендательной системы, используя Aerospike и Spring Boot (Часть 1)

Введение

Рекомендательные системы используются в приложениях для улучшения взаимодействия с пользователями. Например, приложения электронной коммерции рекомендуют продукты покупателям, которые другие покупатели — с похожим поведением — просмотрели, лайкнули или приобрели. Новостные приложения могут также использовать рекомендательные системы в реальном времени. Эти дополнения к стандартным функциям улучшат интерфейс пользователя, увеличат продажи и помогут улучшить лояльность клиентов. Эта статья содержит примеры кода для построения рекомендательной системы реального времени, основанной на косинусном сходстве.

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

Aerospike — высоконадежная NoSQL база данных и низкими задержками, которая масштабируется линейно — таким образом легко ее использовать в качестве хранилища для онлайн приложений. Она хорошо подходит к этому примеру, потому что она масштабируется как горизонтально (увеличивая количество нод на кластере), так и вертикально (поддерживает многопоточность). Aerospike — это in-memory база данных, оптимизированная для использования и DRAM и нативной Flash памяти. Aerospike может похвастаться задержками менее чем в 1 миллисекунду на более чем 100 000 запросов в секунду на один сервер с большим уровнем доступности и немедленной согласованностью данных. Это все автоматизировано и доступно «из коробки».

Что будем разрабатывать?

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

Подробнее

Векторная модель и косинусное сходство (Cosine similarity)

В это статье я хочу ознакомить вас с примером использования векторной модели и рассказать как используется косинусное сходство —  Cosine similarity в информационном поиске.

Документ в векторной модели рассматривается как неупорядоченное множество термов. Термами в информационном поиске называют слова, из которых состоит текст, а также такие элементы текста, как, например, 2010, II-5 или Тянь-Шань.

Различными способами можно определить вес терма в документе — «важность» слова для идентификации данного текста. Например, можно просто подсчитать количество употреблений терма в документе, так называемую частоту терма, — чем чаще слово встречается в документе, тем больший у него будет вес. Если терм не встречается в документе, то его вес в этом документе равен нулю.

Хорошее описание представлено в wiki (на русском, на английском).

Подробнее

Используем TDD в Java 8 Stream

Введение

Идея, которая лежит в упражнениях, приведенных ниже, это изучить Streaming Java 8, используя подход test-driven development (пишем имплементацию для первого теста, убеждаемся, что она работает и двигаемся к следующему).

Каждая секция начинается с темы в форме тестов, которые докажут, что имплементация, которую мы напишем, будет корректно работать. Каждый из тестов сопровождается имплементацией на Java 7 и на Java 8, используя Stream API. Таким способом мы сравним некоторые особенности Java 8 с эквивалентом из Java 7.

Подробнее

Как работает кэш второго уровня Hibernate? Часть 2

В первой части мы рассмотрели концепцию кэша второго уровня и способы его конфигурации. Во второй части рассмотрим стратегии кэширования и конфигурацию EhCache.

Пример проекта в котором Вы можете посмотреть работу кэша и поэксперементировать находится на GitHub.

Подробнее

Как работает кэш второго уровня Hibernate? Примеры

Введение

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

  • Кэш первого уровня в Hibernate включен по умолчанию и работает на уровне сессии. Прочтите здесь подробнее о нем.
  • Кэш второго уровня не включен по умолчанию и доступен глобально на уровне Session Factory.

Один раз, попав в кэш второго уровня объект-сущность, используется на всем протяжении жизни объекта sessionFactory, т.е. область действия кэша  — вся наша программа, а если быть точнее, то, как вы настроите свой кэш, так он себя и поведет. Это также означает, что если фабрика сессий закроется, весь кэш ассоциированный с ней «умрет» и кэш менеджер тоже выключится.

В отличие от кэша первого уровня кэш второго уровня нужно включать непосредственно в настройках Hibernate, и он реализуется провайдером,  сторонней библиотекой кэшем.

Так же это означает что если у Вас есть два инстанса фабрики сессий (нормальное приложение конечно не будет так разрабатываться), Вы будете иметь два кэш менеджера в Вашем приложении и можно получить непредсказуемые результаты.

flush1

В этом туториале я расскажу концепцию кэша второго уровня и приведу примеры использования. Вторую часть вы можете прочитать здесь.

Подробнее

Как работает кэш первого уровня в Hibernate? Примеры

Введение

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

Кэш первого уровня в Hibernate включен по умолчанию и Вам не нужно ничего предпринимать, чтобы включить его. Даже выключить его не удастся. На самом деле, в роли кэша в сессии выступает Persistence Context. В приложении Hibernate, мы говорим что одна сессия имеет один внутренний persistence context. В JPA приложении, EntityManager имеет так же свой persistence context.

Подробнее

Как работает кэш в Hibernate?

Введение

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

Как работает кэш Hibernate?

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

Подробнее

Стратегии загрузки графа объектов в JPA (Часть 2 и вывод)

В первой части  мы рассмотрели статические стратегии загрузки графа объектов. Теперь рассмотрим динамические и сделаем выводы.

Примеры и тесты доступны на гитхаб.

Стратегии динамической загрузки

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

Подробнее