三、锁方式
锁方式是将数据的不一致性转换为数据的不可用性,通过数据的不可用性,消除风险的产生。
锁方式具体的实现方法是:在②服务端处理过程后,对该操作所涉及的数据加锁,使它们处于一种不可用的状态;增加⑤确认传输过程和⑥服务端确认处理过程。当客户端收到应答并处理完毕后,将产生给服务端发一个确认信息,当服务端收到确认后,对第②步锁住的数据进行解锁。如下图所示:

图表 2 锁方式的处理过程
通过上图可以看出,在t1~t4 的时间段内,该笔交易所涉及的数据是加锁的。当③应答传输过程失败时,则不会执行第⑥步的解锁操作。后续涉及这些数据的交易将由于锁的存在而不再进行,因此,不会造成银行的资金损失及信誉损失。
加锁常用两种实现方式:对数据库交易加锁的数据库锁,在应用层对数据加锁的应用锁。锁方式可以根据实际情况决定使用数据库锁或应用锁。
(一)数据库锁
数据库锁利用关系数据库中提供的交易机制对数据进行加锁保护。
数据库操作中,"开始交易(begin work)"和"提交交易(commit work)"之间的操作所涉及的数据将被加锁。在②服务端交易处理过程中执行"开始交易"操作,在⑥服务端确认处理过程执行commit work操作。这样从t1至t4之间,数据是被锁住的。当应答传输过程失败时,相关的数据被锁住,与这些数据相关的后续业务将由于锁的存在而无法进行,这样就不会造成数据不一致的问题。
这种方式避免了风险的产生,程序编写简单,易于使用。但是,数据库的锁要占用比较大的系统资源;数据被锁的时间较长,数据库的交易对数据的锁范围较大,没有针对性。因此,数据库的锁对系统支持大规模并发的能力会产生负面影响。过程③和过程⑤的任何一次失败均会导致交易无法结束,从而也就无法释放相应的资源及数据,从而影响后续业务的处理。
为了避免出现无法释放资源的现象,有些系统采用了结束交易的默认机制。当交易超过一定的时间未结束时,则系统根椐约定,自动进行"提交交易"或"回滚交易(Rollback)"。这种作法实际上可能造成客户端与服务端的数据不一致,使用这种方式的系统一般都具有一个交易中间件,由交易中间件通过XA接口,执行数据库的交易开始及交易结束等与交易有关的操作。
(二)应用锁
应用锁与数据库锁的差别在于,应用锁方式是在应用程序这一层对数据进行加锁。例如一笔存款业务,在第②步服务端完成业务处理后,对进行存款的帐户进行冻结,使其不能发生业务,直到收到客户端发来的确认后,才对该帐户解冻。
应用锁的系统开销小,锁的针对性强,系统的并发能力大。但是应用编程复杂,编程量增加,有时很难确定一笔交易应当锁住的数据。