1 考虑使用JTA等支持分布式事务的事务管理器
这种方案的优势就是直接有现成的解决方案，一般的j2ee服务器都提供了JTA的相关的实现。比较明显的问题就是解决方案太重量级。一般JTA除了服务器要支持，对应的数据库服务厂商一般也要提供相应的商业支持，主要是提供基于 XAResource JDBC驱动，这一些商业上的支持，部分是需要付费的。而且使用XA 数据库驱动，本身可能导致一些潜在的问题，尤其是基于不同的数据库厂商的时候。而XA是基于两阶段提交协议，事务管理器为了完成一个事务，需要多次和数据库通信，效率上比较低。
2 考虑使用数据库自身的数据同步机制
如果新老库的结构基本一样，这种方案还是比较靠谱的。也是比较简单的方案。这种方案的局限性也再次。在本项目中，新库不是一个物理库，而是多个物理库，而老库是一个物理库。如果要用数据库自身的同步机制，涉及到多个库和一个库之间的数据复制。同时由于分表的方案也不一样，导致两边做一个映射的配置，而这个需要在数据库层面进行，逻辑相当的复杂，解决方案成本也比较高。相当于把重要的分库分表的逻辑在数据库这一层重新实现了一份。
其实这个也带来一个维护问题，一旦我们觉得新系统已经足够稳定。应用程序可以之间在写入库进行切换，把老库的逻辑切掉，从而实现了只写新库的需求。整个过程也不需要进行再次发布。而数据库的方案则需要停掉脚本，在多个地方进行配置。
3 在old库存放相同的两张模型表，一张表用于old库的持久化表，另外一张作为临时表，主要是作为需要同步到到新库的数据。如果已经同步到新库，就删除。如果没有同步到新库就同步到新库。这个过程采用定时机制，每分钟定时提取临时表一定数据量的数据，批量导入到新库。通过努力重试，来保证一致性。而新库则需要保证幂等性，保证数据只会同步过一次。一般情况下，则是通过数据特征标识符来识别，这个一般都是数据的唯一性主键。
