OpenDaylight开发者指引之Controller篇(三)


提交失败场景:

一个事务提交失败可是以下原因:

乐观锁失败

另外一个事务提前完成并且以不当的方式修改了同一个节点。这次提交(返回future)将会失败并且抛出OptimisticLockFailedException异常。使用者的义务是创建一个新的事务并提交同样的修改以更新数据树。

警告:

OptimisticLockFailedException异常的发生,往往是多个写操作同时处理相同的数据子树,这样在相同的资源下会发生冲突。
在这种情况下,我们可以多尝试几次,可能会成功。
有一些场景,无论尝试多少次都会成功。因此建议将尝试次数设置为2-3次以避免死循环。

数据校验

数据变化导致本次事务提交没有通过验证提交处理程序或这因为数据结构错误。将会返回DataValidationFailedException异常,用户应该不用尝试创建新的事务,因此它还会在次失败。

两个冲突事务的样例

这个例子演示了两个并发事务,这源自相同的初始状态的数据树,发生了冲突修改。

MD-SAL-translate-picture-5.png

  1. 通过事务txA更新PATH为A。
  2. 通过事务txB更新PATH为B。
  3. 通过txA封装事务并提交。本次提交将会异步处理并且数据树将被更新为A。一旦状态被应用到数据树中,ListenableFuture将以成功事件被返回。
  4. 通过txB封装事务并提交。事务txB的提交将会失败,因为之前事务(txA)在以并发的方式修改了路径PATH。这个通过txB修改的状态将不会被应用。返回的ListenableFuture将抛出OptimisticLockFailedException异常,这就说明了并发事务阻止了事务的提交。


异步尝试多次提交样例

MD-SAL-translate-picture-6.png


兼容性并发更改

两个相同状态的事务间,有一些修改操作被认为是不兼容的。以递归方式遍历每个子树进行冲突检查。

下表显示状态更改和失败是发生在两个并发事务之间,这两个事务都基于相同的初始状态,tx1 比 tx2之前提交。
表7.1 Concurrent change resolution for leaves and leaf-list items
表7.1_Concurrent_change_resolution_for_leaves_and_leaf-list_items_.png


Table 7.2. Concurrent change resolution for containers, lists, list items
Table_7.2_._Concurrent_change_resolution_for_containers,_lists,_list_items_.png

0 个评论

要回复文章请先登录注册