关于使用兵马俑作为持久性解决方案

Terracotta是事务性的（同步块形成修改对象的事务），但不是，也不想符合JTA。这里有一个相当长的关于交易的讨论，以及一些关于兵马俑的常见误解。

我写了一篇关于数据生存期的博客文章，以及它应该如何构建你对识别使用Terracotta的机会的思考。简而言之，Terracotta的最佳位置是您需要持久性和可用性的用例（您的应用程序可能会崩溃，但您仍然需要数据），但数据不一定是长期关键的。

一个规范示例是在 Web 应用中的用户会话上下文中很重要的数据，例如购物车信息。您希望保持该数据的持久性，以便在 Web 应用崩溃时维护购物车。但购物车本身可能会或可能不会被购买。因此，您将它存储在Terracotta中，直到它被购买，然后作为“记录系统”数据保存到数据库中。

从历史上看，您存储在数据库中的数据始终是“记录系统”数据，这些数据对您的业务的长期成功至关重要：客户，订单等。使用今天的“无状态”架构（实际上不是无状态的），我们将所有中期数据推到数据库中。这意味着我们不必要地惩罚我们的数据库（额外的工作和存储）和我们的开发人员（他们必须处理对象关系阻抗不匹配，即使使用ORM）。更好的方法是将其留在对象中，并将其与兵马俑聚类。最近的许多Terracotta用户已经使用这种技术来显着减少他们的数据库占用空间（为他们节省数百万美元），同时提高他们的扩展能力。

存在与数据库的集成点以及如何可靠地进行移交的问题。我们在最近发布的Exakerator（Spring / Terracotta / Tomcat / MySql参考Web应用程序）中将其视为用例。当考试进行时，状态（问题的答案，随机选择顺序，标记为要复习的问题）存储在兵马俑中。但是，当考试结束时，将计算结果分数并将其长期存储在数据库中。

为了安全地执行此操作，我们使用Hibernate键策略，该策略首先在Terracotta中的对象中生成数据库行ID，然后将数据保存到db，然后从Terracotta中删除。如果应用在保存到数据库后但在从 Terracotta 中删除之前崩溃，则此方案具有潜在的争用条件。在这种情况下，应用程序可以尝试将数据重新保存到数据库，可能会创建两行。但是由于预先生成的ID，我们可以判断该行以前是否已成功写入并避免该问题。

总而言之，我不认为兵马俑会很快取代你的数据库。它在操作上太新了，甚至不能在大多数商店中被视为如此。使用模式是不同的。堆中没有查询或 SQL 功能（查询功能由对象模型定义）。我认为它可以并且正在开始取代中期数据使用，这是一种更便宜，更容易的替代方案。但是，有些人开始尝试将其用于长期存储。

Terracotta只是Java。如果你可以被锁定在这项技术中，而不可能只用其他语言编写一些脚本（没有JVM），那就使用它。

文章Kill Your Database with Terracotta真的很好。