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。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值