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

出现这种可能在百万分之一以下。。。

即使是这样，银行对中心的转帐依然会失败，比如：
begin jta transaction
从A行A用户扣款 －－>命名为A操作
往中心发转帐操作请求文件 －－>命名为B操作
commit or rollback

由于使用了两阶段提交，所以提交事务时，将发生
prepared commit A
prepared commit B （发送转帐请求文件到中心，并接收到中心回应收到文件信息)
commit A
commit B （发送确认信息到中心）

在这个操作中，依然会发生 commitA成功，commitB失败

中心和各个银行间事务应该也是类似。

这个我碰到过，结果只有等到银行对帐后才返回的。

这个数据是怎么来的 ，貌似遇到失败的兄弟还不少啊

不可能靠数据库来保持事务的，一个用户转账需要好几分钟，占用一个事务，别的用户都要等，这是不可能的，数据库也没有能力支持这么多的并发连接。
只能在系统设计的时候尽量多的考虑到各种异常情况，留下记录，制定一个尽量保险的对账策略和异常处理方式，然后严格的对操作岗位进行管理。解决了这些问题，最终的正确性是有保证的。
不仅银行，电信、电力的账务也是这么干的，他们与银行的接口，还有系统内部都要考虑异常情况，每天进行对账。

ATM也不是inter网。

是不可能靠数据库保持事务，可JTA不仅仅是数据库事务，只要支持XA的资源，就可以实现事务管理。

如果在柜台操作就是内网了，柜台操作应该一样存在上面说的情况吧。

一般都用Tuxedo这种中间件去处理吧

关于转帐这个事, 其实更多的是法律上, 或者规范上规定得很严格(这些都是对人的, 对于失败后, 人为的处理).

所以一般转帐的系统都是挺简单的.

没有哪个系统是能保证事务完整的, 总有一些极少的情况会失败. 很多完美的词语只不过是广告.