Терракота транзакционная (синхронизированные блоки формируют транзакции измененных объектов), но не является и не хочет быть JTA-совместимой. Здесь довольно длинное обсуждение транзакций и некоторые распространенные заблуждения о терракоте здесь .
Я написал в блоге о времени жизни данных и о том, как это должно отражать ваши мысли об определении возможностей использования терракоты. Короче говоря, сладкое место Terracotta - это тот случай, когда вам нужны постоянство и доступность (ваше приложение может произойти сбой, но вам все равно нужны данные), но когда данные не обязательно являются критически важными в долгосрочной перспективе.
Каноническим примером являются данные, важные в контексте пользовательского сеанса в веб-приложении, такие как информация о корзине. Вы хотите сохранить эти данные постоянными, чтобы в случае сбоя веб-приложения вы сохраняли корзину покупок. Но сама корзина может или не может быть куплена. Таким образом, вы храните его в Terracotta до его покупки, а затем сохраняете в базу данных как данные «системы записи».
Исторически сложилось, что данные, которые вы хранили в базе данных, всегда были «системой записи» данных, которые имели решающее значение для долгосрочного успеха вашего бизнеса: клиенты, заказы и т. Д. С сегодняшними «архитектурами без сохранения состояния» (которые действительно не нужны). мы сохраняем все среднесрочные данные в базе данных. Это означает, что мы без необходимости наказываем нашу базу данных (с дополнительной работой и хранением) и наших разработчиков (которым приходится обрабатывать несоответствие объектно-реляционного импеданса, даже если используется ORM). Лучшим подходом является оставить его в объектах и кластеризовать его с помощью терракоты. Ряд недавних пользователей Terracotta использовали эту технику, чтобы значительно сократить объем своей базы данных (сэкономив им миллионы долларов) и одновременно увеличив свою способность к масштабированию.
Возникает вопрос о точке интеграции с базой данных и о том, как обеспечить надежную передачу обслуживания. Мы рассматривали это как пример использования в недавно выпущенном Examinator (справочное веб-приложение Spring / Terracotta / Tomcat / MySql). Когда экзамены проводятся, состояние (ответы на вопросы, рандомизированные варианты выбора, вопросы, отмеченные для проверки) сохраняется в терракоте. Но когда экзамены завершены, итоговая оценка рассчитывается и сохраняется в базе данных в течение длительного времени.
Чтобы сделать это безопасно, мы используем стратегию ключа Hibernate, которая сначала генерирует идентификатор строки базы данных в объекте в Терракоте, затем сохраняет данные в БД, а затем удаляет из Терракоты. Этот сценарий имеет потенциальное состояние гонки, если приложение аварийно завершает работу после сохранения в базе данных, но перед удалением из терракоты. В этом случае приложение может попытаться повторно сохранить данные в БД, возможно, создав две строки. Но благодаря предварительно сгенерированному идентификатору мы можем определить, была ли ранее успешно записана строка, и избежать этой проблемы.
Таким образом, я не думаю, что Терракота заменит вашу БД в ближайшее время. Это слишком ново в эксплуатации, чтобы даже считаться таковым в большинстве магазинов. Модель использования сильно отличается. В куче нет запросов или возможностей SQL (ваша возможность запросов определяется вашей объектной моделью). Я думаю, что он может и начинает заменять среднесрочное использование данных, когда это намного более дешевая и простая альтернатива. Однако некоторые люди начинают экспериментировать с ним для длительного хранения.