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