SRP的一个实例（2）

以前的这个设计，考虑到了Java Sheduler会被重启造成死锁，所以Scheduler重启时释放了所有的锁。但这样的方案存在以下问题： 如果Java Scheduler重启后前一个存储过程还没有执行完，由于重启释放了锁，下一个请求会被并发。这次出bug也正是由于这个原因。

究其原因，这是一个违反了Single Responsiblity Principle的设计。按理说，像这种需要并发控制的过程，应该在其内部自我保证不可重入。退一步说，即使由于某种原因（不愿意修改以前代码），至少应该在数据库层次保证这点。而这个设计却将并发控制的责任交由网络那头的Java控制，就将整个过程不出错的前提由存储过程没有设计错（数据库没有出错）扩大至了整个系统（网络，Java端）不出错。这世上本没有救世主，依赖别的控制模块总是迟早有报应的。

换句话说，一个好的设计应该使Java和DB端的耦合尽可能松，而这个设计却使两者紧耦合了。

基于此，我改进了原设计 

 

Java Side:

public   void  run( string  taskName,  string []  params ) ... {
    callBroker(taskName,params);
}

DB Broker Side:
public   void  run( string  taskName, string []  params ) ... {
   switch (taskName)...{
       case 'task1':
          select lastStart,lastEnd from JS_SCHEDULER where name='task1';
          //First time run task1
          if (lastStart==null)...{
                   insert into JS_SCHEDULER (lastStart) values sysdate;
              }
              else...{
                   if (lastEnd==null &&sysdate-lastStart>TIMEOUT)...{
                        // 也许上一次没运行完，也许上一次运行遇到了死锁
                        // 请求人工干预
                        sendWarningMail();
                         return();
                   }
                   else...{
                        //没有其它进程
                        if (lastEnd>LastStart)...{
                                //加锁
                                Update JS_SCHEDULER set lastStart=sysdate where name=''task1';
                                param0=Convert_Param(params[0];
                                param1=Convert_Param(params[1];
                                ...
                                task1(param0,param1,...);
                                //解锁
                                Update JS_SCHEDULER set lastEnd=sysdate where name=''task1';
                        }
                         //有其它进程在跑
                         else...{
                               return();
                          }
                   }
              }
          }
       break;
       ...
       default:
        throw exception;
   }
}

 

这里在数据库端引入了一个Broker存储过程，负责同步。Java端只需要调用Broker，不再用考虑同步了。实际的Broker是用PL/SQL写的，不过这里伪代码是Java的(PL/SQL的语法是在不敢恭维，每次写都像回到10年前写Pascal)。Broker采用时间锁，对于每个其知道的存储过程，负责参数转换、加锁、调用、解锁等事宜。如果发现某个存储过程跑的时间太长，可能是数据库中间被重启了，可能是其确实要跑很长时间，也可能是其死锁了。为防止并发，Broker不能擅自作主，而是要求人工干预。

总的来说，这套框架可以满足目前的所有需求。但是，这仍然是一个UGLY的设计。这只是将依赖缩小到了数据库端。我还是觉得有很多Bad Smell，正在考虑更好的解决方式ing。