activiti-5.1核心之CommandContext

众所周知，从以前的jbpm到现今的activiti，流程引擎的内部执行模式是command模式，不管是启动流程，还是推动流程等等，都采用了command的execute方法。而command执行依赖于CommandContext，直译就是command的上下文，那么，我们就来看看CommandContext里面的内容。

首先是CommandContext本身的类变量和实例变量： 

private static Logger log = Logger.getLogger(CommandContext.class.getName());

private static final ThreadLocal<Stack<CommandContext>> txContextStacks = new ThreadLocal<Stack<CommandContext>>();

protected Command< ? > command;

protected TransactionContext transactionContext;

protected Map<Class< ? >, Session> sessions = new HashMap<Class< ? >, Session>();

protected Throwable exception = null;

protected ProcessEngineConfigurationImpl processEngineConfiguration;

其实从这个变量声明，我们就能够大致看出CommandContext的管辖范围，首先是提供线程安全的副本栈txContextStacks，然后是在当前上下文执行的command，事务上下文transactionContext，会话集合sessions ，流程引擎配置类processEngineConfiguration，至于log和exception肯定就不用说了。当然，实际来说，transactionContext其实只是为session管理服务的，稍后可见。

为了避免线程冲突，每个command都在一个独立的commandContext中执行，如下：

 

  public static void setCurrentCommandContext(CommandContext commandContext) {

    getContextStack(true).push(commandContext);

  }

 

  public static void removeCurrentCommandContext() {

    getContextStack(true).pop();

  }

 

  public static CommandContext getCurrent() {

    Stack<CommandContext> contextStack = getContextStack(false);

    if ((contextStack == null) || (contextStack.isEmpty())) {

      return null;

    }

    return contextStack.peek();//在非出栈情况下获取栈顶的CommandContext

  }

 

  private static Stack<CommandContext> getContextStack(boolean isInitializationRequired) {

    Stack<CommandContext> txContextStack = txContextStacks.get();//获取当前线程一个栈变量副本

    if (txContextStack == null && isInitializationRequired) {//初始化栈

      txContextStack = new Stack<CommandContext>();

      txContextStacks.set(txContextStack);

    }

    return txContextStack;

  }

看到这里，大家可能会产生一个疑问，ThreadLocal为啥限定类型为Stack，而不是Map之类的Collection呢？其实，在了解了command的执行过程后，就不会有这个问题了。

一个command在生成之后交由CommandExecutor执行时，要经过一个CommandInterceptor，这个拦截器做了什么呢？它会使用一个CommandContextFactory为这个command生成【commandContextFactory.createCommandContext(command)】并指定【CommandContext.setCurrentCommandContext(context)】一个CommandContext，然后CommandExecutor执行command，执行完毕后，CommandInterceptor再将指定的CommandContext关闭【context.close()】并移除【CommandContext.removeCurrentCommandContext()】。在这个过程中我们可以看到，CommandContext的生成和移除正好对应了入栈和出栈，简单来说，就是 创建CommandContext--执行command--移除CommandContext 这样一个过程，这个生命周期用栈来管理正是天作之合，如果用collection，势必增加不必要的开销且别扭。

下面看看CommandContext的关闭，里头干了不少事情啊  

public void close() {

    // the intention of this method is that all resources are closed properly,

    // even

    // if exceptions occur in close or flush methods of the sessions or the

    // transaction context.

 

    try {

      try {

        try {

 

          if (exception == null) {

            flushSessions();//会话提交

          }

 

        } catch (Throwable exception) {

          exception(exception);

        } finally {

 

          try {

            if (exception == null) {

              transactionContext.commit();//事务提交

            }

          } catch (Throwable exception) {

            exception(exception);

          }

 

          if (exception != null) {

            log.log(Level.SEVERE, "Error while closing command context", exception);

            transactionContext.rollback();//遇到异常事务回滚

          }

        }

      } catch (Throwable exception) {

        exception(exception);

      } finally {

        closeSessions();//关闭会话

 

      }

    } catch (Throwable exception) {

      exception(exception);

    } 

 

    // rethrow the original exception if there was one

    if (exception != null) {

      if (exception instanceof Error) {

        throw (Error) exception;

      } else if (exception instanceof RuntimeException) {

        throw (RuntimeException) exception;

      } else {

        throw new ActivitiException("exception while executing command " + command, exception);

      }

    }

  }

如上可见，command执行完毕后的会话、事务和异常都在这儿统一管理了。

之后就是通过map获取会话的一堆代码了：

  public <T> T getSession(Class<T> sessionClass) {

    Session session = sessions.get(sessionClass);

    if (session == null) {

      SessionFactory sessionFactory = processEngineConfiguration.getSessionFactories().get(sessionClass);

      if (sessionFactory==null) {

        throw new ActivitiException("no session factory configured for "+sessionClass.getName());

      }

      session = sessionFactory.openSession();

      sessions.put(sessionClass, session);

    }

 

    return (T) session;

  }

 

  public RepositorySession getRepositorySession() {

    return getSession(RepositorySession.class);

  }

  public RuntimeSession getRuntimeSession() {

    return getSession(RuntimeSession.class);

  }

  public IdentitySession getIdentitySession() {

    return getSession(IdentitySession.class);

  }

  public MessageSession getMessageSession() {

    return getSession(MessageSession.class);

  }

  public TimerSession getTimerSession() {

    return getSession(TimerSession.class);

  }

  public TaskSession getTaskSession() {

    return getSession(TaskSession.class);

  }

  public HistorySession getHistorySession() {

    return getSession(HistorySession.class);

  }

  public ManagementSession getManagementSession() {

    return getSession(ManagementSession.class);

  }

  public DbSqlSession getDbSqlSession() {

    return getSession(DbSqlSession.class);

  }

我得说，这一坨东西看上去真丑陋，不过考虑到这块估计也没什么扩展和改动了，就这样吧。