有谁知道银行的跨行转帐是怎么保证交易的原子性和一致性？

最近在看《Java Transaction Design Strategies》，想到了对事务要求比较严格的银行间转帐这种事务，夸行转帐是怎么保证事务的原子性和一致性呢？首先我能想到的就是使用JTA，用两阶段提交，可是仔细一想，发现还是不能完整保证：
假设转帐步骤如下：
begin jta transaction
从A行A用户扣款 －－>命名为A操作
往B行B用户存款 －－>命名为B操作
commit or rollback

由于使用了两阶段提交，所以提交事务时，将发生
prepared commit A
prepared commit B
commit A
commit B

假如在prepared都没有任何问题，然后commit A成功，commitB时发生网络故障，失败，然后试图rollback A，发现与A数据库服务器网络也在这一瞬间发生故障，那就造成了从A扣款成功，但没能往B帐号存款。


我没有任何银行项目经验，当然这都是我的想象和假设

再胡思乱想一下，跨行间转帐似乎也不太可能依赖数据库间的事务，因为对方银行不可能提供你直接操作数据库吧，肯定也是提供一个接口供对方银行使用。

握手-确认-再确认

BTW，总归会有出错的时候，一般是每天要对一次帐。

也就是没办法完全保证事务的完整性喽？那是否会出现转帐失败，自己帐号上的钱也被扣了，要等银行对帐完才能恢复？我自己是没碰到过，有人碰到这种情况吗

我有两个同事，都曾经从中国银行的ATM机取钱，结果卡上的钱扣了，可是钱没出来。
都是等银行对完帐以后，然后再还给他们。
连本行都没保证，别说跨行了，只是失误率比较低吧。

那银行是怎么对帐的，假如说，ATM机上剩下的现钞比银行对帐的结果多，可银行不认，消费者怎么办？或者ATM机上多出来的钱被银行管ATM机的人黑了

5楼说的是对的. 像在美国那边, 我们是通过ACH文件来转账的, 发这个ACH文件到某个中心去, 这个中心会帮你调度等等一些东西(真正转钱的,和各银行联系的), 如果出错了, 会在几天内发一个文件回来, 如果过了这么多天都没有收到什么消息, 就默认成功了. 如果出错了, 系统之间(你的转帐系统与中心)无法配合(就是各不认错)一定的次数, 这个事就要用法律解决, 系统这间再也不会理这件事了.

哦，原来是这样，那国内估计也是通过银联之类的第三方机构来调度吧.

至于那个中心怎么样保证它的事务完整性, 应该要看它的事务设计了.

不过有很多事都不是能完美的. 只能说99%可能就够了. 1%让人工去干预.

多设了个中心，主要简化的是各个银行间的协调，由多点变为单点，但中心依然是需要面对多点，也就是事务依然可能会失败，需要人工干预