目前的银行柜面业务处理系统，基本都是b/s或c/s架构的，柜面系统通过网络与前置系统或者核心系统相互通讯。由于网络的不可靠性，常常出现传输过程中交易数据的丢失，造成客户端与服务端的交易不完整或数据不一致，这样会对银行造成相应的现成风险和潜在风险。如何控制数据的一致性，是目前银行系统联机事务交易处理所必须考虑的问题。
一、 导致数据不一致的原因
在客户/服务器结构的联机交易处理系统中，一笔交易至少包含如下图所示的四个过程：①请求传输过程；②服务端交易处理过程；③应答传输过程；④客户端处理应答过程。
由于网络传输的不可靠性，必然有"③应答传输过程" 失败的情况。在这种情况下，就产生了服务端与客户端交易状态的不一致性问题：在服务端，该笔交易已处理或完成；在客户端，由于没有收到应答，该笔交易是失败的。
这种客户端及服务端的不一致性，会给银行带来资金风险和信誉风险。当该笔交易是增加客户的可用资金时，产生了资金风险，当该笔交易是减小客户的可用资金时，产生了信誉风险。例如一笔存款交易产生数据不一致时，在服务端，客户的帐户余额已增加，而在柜台，该笔业务失败，存款并末收入，从而造成客户的余额虚增，客户可以通过正常的途径使用该笔资金，这将造成银行资金损失。一笔取款交易产生数据不一致时，在主机端，客户的帐户余额已减少，而在柜台，该笔业务失败，客户并未取到款。如果客户发现这一情况，将会造成银行的信誉损失。
二、 冲正与重复办理方式
目前大部分银行业务处理系统采用冲正或重复办理的方式，了解决数据不一致的问题。这两种方式的基本思想，都是当数据不一致性问题发生后，通过事后附加的干预过程来进行补救。
（一） 冲正方式
冲正方式下，一笔交易以客户端为准，客户端完成，该笔交易才完成，客户端失败，则该笔交易失败。当应答传输过程失败，前端认为该笔交易失败，将产生一笔冲正交易。该笔冲正交易将取消上一笔交易的结果，从而恢复客户端及服务端的数据一致性。
按产生冲正交易的时机，可以分为三种：
1、立即冲正，是在一笔交易超时无应答时，立即发出冲正；
2、定时冲正，是指按固定的时间间隔，发出冲正交易；
3、当一笔交易未成功时，在做下一笔交易时，先自动做一个冲正交易，当冲正交易完成后，才执行正常交易。目前，POS系统广泛使用的是下一笔交易冲正的方式。
冲正方式程序控制简单，适应性广。但这种方式无法确保冲正成功的时间，从而也就无法控制风险存在的时间。一个极端的情况是，通讯故障是由于物理线路中断造成的，在线路恢复正常前，冲正交易无法完成，风险将一直存在。
（二）重复办理方式
重复办理方式下，一笔交易以服务端为准，服务端处理成功，无论客户端是否收到结果，均认为该笔交易成功。当应答传输过程失败造成客户端交易失败，客户端必须重复办理该笔交易，在服务端，收到重复的交易请求，若该笔交易已处理，则将上笔交易的结果作为本次交易的处理结果返回，若未处理，则按正常交易进行处理。
这种方式的优点在于控制简单，易于实现。局限性基本同冲正方式，即无法控制风险存在的时间。另外，以服务端为准的条件使它的使用范围受到一定的限制。在对公会计系统中，通常采用重复办理的方式。
三、锁方式
锁方式是将数据的不一致性转换为数据的不可用性，通过数据的不可用性，消除风险的产生。
锁方式具体的实现方法是：在②服务端处理过程后，对该操作所涉及的数据加锁，使它们处于一种不可用的状态；增加⑤确认传输过程和⑥服务端确认处理过程。当客户端收到应答并处理完毕后，将产生给服务端发一个确认信息，当服务端收到确认后，对第②步锁住的数据进行解锁。如下图所示：
通过上图可以看出，在t1~t4 的时间段内，该笔交易所涉及的数据是加锁的。当③应答传输过程失败时，则不会执行第⑥步的解锁操作。后续涉及这些数据的交易将由于锁的存在而不再进行，因此，不会造成银行的资金损失及信誉损失。
加锁常用两种实现方式：对数据库交易加锁的数据库锁，在应用层对数据加锁的应用锁。锁方式可以根据实际情况决定使用数据库锁或应用锁。
（一）数据库锁
数据库锁利用关系数据库中提供的交易机制对数据进行加锁保护。
数据库操作中，"开始交易（begin work）"和"提交交易(commit work)"之间的操作所涉及的数据将被加锁。在②服务端交易处理过程中执行"开始交易"操作，在⑥服务端确认处理过程执行commit work操作。这样从t1至t4之间，数据是被锁住的。当应答传输过程失败时，相关的数据被锁住，与这些数据相关的后续业务将由于锁的存在而无法进行，这样就不会造成数据不一致的问题。
这种方式避免了风险的产生，程序编写简单，易于使用。但是，数据库的锁要占用比较大的系统资源；数据被锁的时间较长，数据库的交易对数据的锁范围较大，没有针对性。因此，数据库的锁对系统支持大规模并发的能力会产生负面影响。过程③和过程⑤的任何一次失败均会导致交易无法结束，从而也就无法释放相应的资源及数据，从而影响后续业务的处理。
为了避免出现无法释放资源的现象，有些系统采用了结束交易的默认机制。当交易超过一定的时间未结束时，则系统根椐约定，自动进行"提交交易"或"回滚交易（Rollback）"。这种作法实际上可能造成客户端与服务端的数据不一致，使用这种方式的系统一般都具有一个交易中间件，由交易中间件通过XA接口，执行数据库的交易开始及交易结束等与交易有关的操作。
（二）应用锁
应用锁与数据库锁的差别在于，应用锁方式是在应用程序这一层对数据进行加锁。例如一笔存款业务，在第②步服务端完成业务处理后，对进行存款的帐户进行冻结，使其不能发生业务，直到收到客户端发来的确认后，才对该帐户解冻。
应用锁的系统开销小，锁的针对性强，系统的并发能力大。但是应用编程复杂，编程量增加，有时很难确定一笔交易应当锁住的数据。
三、 TongEASY方案：锁与自动确认/冲正结合
从银行业务角度来看，控制风险是首要的，因此一个方案首先必须实现对风险的有效控制。虽然锁方式可以有效地控制风险，但这种方式对系统处理能力及效率会有一定的影响，如何将这种方式对系统的影响控制在可以接受的范围，是解决问题的关键所在。
通科技公司的交易中间件TongEASY综合上述几种方式的优点，提供了一种解决数据一致性问题的方案，即锁与自动确认/冲正结合的方式：利用锁方式控制数据一致性问题，利用确认/冲正方式释放锁占用的资源。
TongEASY以锁方式为基础，增加以第⑦个处理过程：确认/冲正的应答传输过程。当服务端接收到客户端的确认/冲正后，服务端将发回一个确认/冲正的应答。TongEASY只有在收到确认/冲正的应答后，才认为该笔交易已处理结束，否则将重复发确认/冲正。处理过程如下图所示：
当③应答传输过程失败时，TongEASY将产生一个"冲正确认"发给服务端，服务端收到"冲正确认"后，则进行冲正操作，取消该笔交易的操作。当⑤确认传输过程或⑦确认应答传输过程失败时，TongEASY将核对交易结果并按一定的时间间隔重复执行⑤确认传输过程，直到过程⑤及⑦均正常完成为止。服务端在进行⑥确认处理过程时，若收到的确认是"正常确认"，则对相关数据解除应用锁；若收到的确认是"冲正确认"，则对相关数据解除应用锁并进行冲正操作。若收到的"确认"已处理过，则直接发回确认应答信息。
TongEASY方式相对于锁方式而言，避免了由于单次通讯故障造成资源无法释放，在解决数据不一致性问题的同时，减少了系统资源占用现象，避免了系统在长时间运行后，由于大量资源无法释放而造成系统的性能下降。
四、 总结
冲正方式及重复办理方式虽然简单、方便，但却无法防止风险的产生，无法有效控制风险存在时间。
数据库锁及应用锁的方式可以防止风险的产生，但对系统的运行效率，特别是会影响系统支持大规模并发的能力，在极端的情况下，会影响系统的正常使用。
TongEASY提供的锁与冲正结合的方式是对锁机制的一种改进，它不但可以防止风险的产生，同时可以减少由于通讯故障造成的资源占用，不失为一种适合中国国情的解决方法。