极端事务处理模式：Write-behind缓存

核心提示： 若要配置JPA加载器，就必须修改添加到META-INF目录下的objectgrid.xml和persistence.xml文件，极端事务处理模式：Write-behind缓存(4)，加载器 bean可以与必要的实体类名一起被加入到objectgrid.xml中，在objectgrid.xml中必

若要配置JPA加载器，就必须修改添加到META-INF目录下的objectgrid.xml和persistence.xml文件。加载器 bean可以与必要的实体类名一起被加入到objectgrid.xml中。在objectgrid.xml中必须定义事务的回调函数，这样就可以接收事务提交或回滚的事件，并将其发送到JPA层。persistence.xml文件则表示一个特殊的JPA提供器，它针对具有提供器的特定属性的持久化单元。

考察一个商业案例

考察一个在线的银行网站，当用户数增长时，响应时间变慢，且存在可伸缩性问题。他们需要在现有硬件环境下支持客户需求。接下来，我们就以这一案例来展示write-behind特性是如何帮助他们解决这一问题的。

用例：门户个性化

与直接从数据库中拉取用户个人信息不同，我们首先会将数据库中取出的个人信息，预先加载到缓存中。这意味着缓存是为读请求服务，而不是数据库。在旧系统中，个人信息的更新同样是直接写入到数据库。在可接受的响应时间内，随着数据库服务器的超负荷，每秒钟发生的并发更新数将受到限制。新的系统则是将个人信息的变更写入到网格中，然后使用write-behind技术将这些变更推到数据库中。这就保证了服务的质量和性能，并完全解除了单实例数据库与读写个人信息操作之间的耦合。现在，客户只需要将更多的JVMs/server添加到网格中，就可以扩大个人信息服务的规模。数据库不再成为瓶颈，因为发送到后端的事务数得到了锐减。更快的响应时间带来更快的页面加载，大大改善了用户体验，有效地利用了个人信息服务器的规模，提高了可用性，因为数据库不再成为单一失败点。

对于本用例，我们对DB2O数据库采用了WebSphere eXtreme Scale以及OpenJPA提供器。这一场景的数据模型为User与UserAccount以及UserTransaction之间的一对多关系。下面为User类的代码片段，展现了这样一种关系：