使用Terracotta作为持久性解决方案
使用Terracotta作为持久性解决方案（替换数据库）是不是一个好主意？ 我特别想知道数据完整性问题和对事务系统的支持。
Terracotta是事务性的 （同步块形成修改对象的事务）但不是也不希望符合JTA。 关于交易以及对兵马俑的一些常见误解存在相当冗长的讨论。
我写了一篇关于数据生命周期的博客文章，以及如何构建您对识别使用兵马俑的机会的想法。 简而言之，Terracotta的最佳位置是您需要持久性和可用性的用例（您的应用程序可能崩溃，但您仍然需要数据）但数据不一定是长期关键的。
规范示例是在Web应用中的用户会话的上下文中重要的数据，例如购物车信息。 您希望保持该数据的持久性，以便在您的Web应用程序崩溃时，维护购物车。 但购物车本身可能会或可能不会被购买。 因此，您将其存储在Terracotta中直到购买，然后将其作为“记录系统”数据保存到数据库中。
从历史上看，您存储在数据库中的数据始终是“记录系统”数据，这对您的业务的长期成功至关重要：客户，订单等。使用当今的“无状态”架构（实际上并非无状态） ，我们将所有中期数据推送到数据库。 这意味着我们不必要地惩罚我们的数据库（有额外的工作和存储）和我们的开发人员（他们必须处理对象 – 关系阻抗不匹配，即使使用ORM）。 更好的方法是将其留在对象中并使用Terracotta进行聚类。 最近一些Terracotta用户使用这种技术来显着减少他们的数据库占用空间（节省数百万美元），同时提高他们的扩展能力。
存在与数据库的集成点以及如何可靠地进行切换的问题。 我们在最近发布的Examinator （Spring / Terracotta / Tomcat / MySql参考Web应用程序）中看到了这个用例。 考试进行时，状态（问题答案，随机选择顺序，标记为复习的问题）存储在Terracotta中。 但是，当考试完成后，计算结果得分并长期存储在数据库中。
为了安全地执行此操作，我们使用Hibernate密钥策略，首先在Terracotta中的对象中生成数据库行id，然后将数据保存到db，然后从Terracotta中删除。 如果应用程序在保存到数据库之后但在从Terracotta中删除之前崩溃，则此方案具有潜在的竞争条件。 在这种情况下，应用程序可能会尝试将数据重新保存到db，可能会创建两行。 但是由于预先生成的ID，我们可以判断该行是否先前已成功写入并避免该问题。
总之，我认为Terracotta不会很快取代您的数据库。 在大多数商店中甚至被认为是这样的新操作。 使用模式有所不同。 堆中没有查询或SQLfunction（您的查询function由对象模型定义）。 我认为它可以而且正在开始取代中期数据使用，因为它是一种更便宜，更容易的替代方案。 然而，有些人开始尝试长期存储。
兵马俑只是Java。 如果您可以锁定此技术，而无法在其他语言中编写一些脚本（没有JVM），那么请继续使用它。
文章用Terracotta杀死你的数据库非常好。