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

银行的交易处理都不会用到我们常说的事务.银行里的大多交易是跨多个系统和数据库处理的,因此光靠一般的事务是解决不了问题的.
简单说来,银行对交易的原子保证一般是通过"冲正"来处理,
对于跨行或批量数据交易,都是通过文件批量传送,并加上冲正和对账.这样交差验证后错误率就降低了,如果有错,会在第二天以后通知客户,或退帐.
而这些环节里有一个非常重要的东东:流水. 如交易流水,帐户变更流水等.在人工处理里就全靠这些流水来处理.
比如,你在ATM机上取钱时,如果帐被划走了,但钱没有吐出来,那银行在夜间对账时就会借贷不平,然后再通过查询流水便可以找到出问题的账户.

PS:银行会定期地进行扎账,这个扎账过程很复杂且耗时,一般需要一个晚上的时间系统才能结算完一个分行的数量.
通过扎账就可以发现系统的借贷不平问题.

讨论到现在，关于事务的问题基本可以定论了，或者讨论银行转帐业务异常设计更有意义，如何简单完备，系统异常的时候可以方便的追踪到每个异常并恢复，召唤做过相关业务的兄弟现身传道。

原来是这样阿！（原始的人工辅助处理，才是最智能与全能的）开了眼了。

另外谁能说说其他的关于业务分布式的实现方式么？
诸如：电信的夸系统（电信与网通）记账／日志、国家－省－市的电子政务平台间的公文流转等等。

说说我们现在的系统，是一个基金交易电文（xml）传送的控制系统，提交时，把相关信息（xml）发送给一个交易结算中心，然后返回成功或失败，这一步执行后，需要更新本地数据库的状态信息。第一不执行成功之后，更新数据库状态有可能会失败（当然概率很低），现在的做法就是只是简单的给出提示，传送电文成功，更新数据库失败（台湾那边的designer设计的，用户也勉强接受这种做法），方法简陋之至，目前还没什么好的思路，请大伙支支招。
ps：原先有个想法就是在发送前记录操作日志，发送后，再记录日志，以作为后续人工处理的检查依据，可后来一想，发送成功后，记录日志，依然时可能失败的，又回到的原先的情况。如果消息不记录到数据库，而是发送一个jms，也是同样的情况。

你这些都是大问题，都不是一两句话能说清楚的。

是大问题没错，
但是这两年不少中小型系统／平台的开发中也经常会遇到这种业务上天然分布式的东西。
关键是之前的想法上，将 银行／金融／电信／电力／政府／铁路售票 等行业的系统实现神话了，以为完全是由软件编程给予保障的。

还是希望多些这方面的经验介绍。
现在业务上分布式的大大小小项目还是比较多，即使你的第一期不是分布式的，后续的开发也可能马上会遇到。

先更新数据库，后传送电文不就可以了？
传送电文失败抛出异常可以让数据库操作回滚

更新数据状态需要根据传送电文的状态信息。
而且，即使先更新数据库，后传送电文，失败了回滚数据库当然没问题，成功了提交数据库依然会失败，没什么两样，而且还延长了数据库事务的时间，占用了资源。

很难保证一步到位
要人工对帐的