Activiti内部实现中,各主要部件关系
对外,提供Service服务,它是无状态的。
这些Service包括:
- protected RepositoryService repositoryService = new RepositoryServiceImpl();
- protected RuntimeService runtimeService = new RuntimeServiceImpl();
- protected HistoryService historyService = new HistoryServiceImpl();
- protected IdentityService identityService = new IdentityServiceImpl();
- protected TaskService taskService = new TaskServiceImpl();
- protected FormService formService = new FormServiceImpl();
- protected ManagementService managementService = new ManagementServiceImpl();
对service提供的服务,基本上每一个需要执行具体任务的方法,都有一个对应的Command实现与之对应。
- 一般来说,一个Command对应一个完整事物;
- 调用Command之前,都会经过CommandInterceptor,这个在初始化时就确定了,如:LogInterceptor >> CommandContextInterceptor >> CommandInvoker
如果Command不涉及节点相关内容,而是直接对数据库进行操作,则直接关联DB,入DbSqlSession的缓存;
否则,一般会通过ExecutionEntity来完成具体的操作,这里,封装了一些基本的原子操作,它们都是AtomicOperation的接口实现:
流程实例类:
- AtomicOperationProcessStart
- AtomicOperationProcessStartInitial
- AtomicOperationProcessEnd
流程活动类:
- AtomicOperationActivityStart
- AtomicOperationActivityExecute
- AtomicOperationActivityEnd
流程活动流转类:
- AtomicOperationTransitionNotifyListenerEnd
- AtomicOperationTransitionDestroyScope
- AtomicOperationTransitionNotifyListenerTake
- AtomicOperationTransitionCreateScope
- AtomicOperationTransitionNotifyListenerStart
流程执行树清理类:
- AtomicOperationDeleteCascade
- AtomicOperationDeleteCascadeFireActivityEnd
其中,活动执行时,具体动作是由ActivityBehavior的实现类来决定的:
关于默认ID生成器
Activiti的默认生成器是DbIdGenerator,实际是一次从数据库中取一块数据,然后慢慢用,用完后再取。
/**
* @author Tom Baeyens
*/
public class DbIdGenerator implements IdGenerator {
protected int idBlockSize;
protected long nextId = 0;
protected long lastId = -1;
protected CommandExecutor commandExecutor;
protected CommandConfig commandConfig;
public synchronized String getNextId() {
if (lastId<nextId) {
getNewBlock();
}
long _nextId = nextId++;
return Long.toString(_nextId);
}
protected synchronized void getNewBlock() {
IdBlock idBlock = commandExecutor.execute(commandConfig, new GetNextIdBlockCmd(idBlockSize));
this.nextId = idBlock.getNextId();
this.lastId = idBlock.getLastId();
}
- 在ProcessEngineConfiguration中定义的块默认大小100;
- 在ProcessEngineComfigurationImpl中,完成初始化:
// id generator /
protected void initIdGenerator() {
if (idGenerator==null) {
CommandExecutor idGeneratorCommandExecutor = null;
if (idGeneratorDataSource!=null) {
ProcessEngineConfigurationImpl processEngineConfiguration = new StandaloneProcessEngineConfiguration();
processEngineConfiguration.setDataSource(idGeneratorDataSource);
processEngineConfiguration.setDatabaseSchemaUpdate(DB_SCHEMA_UPDATE_FALSE);
processEngineConfiguration.init();
idGeneratorCommandExecutor = processEngineConfiguration.getCommandExecutor();
} else if (idGeneratorDataSourceJndiName!=null) {
ProcessEngineConfigurationImpl processEngineConfiguration = new StandaloneProcessEngineConfiguration();
processEngineConfiguration.setDataSourceJndiName(idGeneratorDataSourceJndiName);
processEngineConfiguration.setDatabaseSchemaUpdate(DB_SCHEMA_UPDATE_FALSE);
processEngineConfiguration.init();
idGeneratorCommandExecutor = processEngineConfiguration.getCommandExecutor();
} else {
idGeneratorCommandExecutor = getCommandExecutor();
}
DbIdGenerator dbIdGenerator = new DbIdGenerator();
dbIdGenerator.setIdBlockSize(idBlockSize);
dbIdGenerator.setCommandExecutor(idGeneratorCommandExecutor);
dbIdGenerator.setCommandConfig(getDefaultCommandConfig().transactionRequiresNew());
idGenerator = dbIdGenerator;
}
}
注意:此处对getNextId()方法加了synchronize关键字,它在单机部署下,确定不会出现网上分析的什么ID重复问题。
关于task的start_time_字段取值问题
在TaskEntity中:
/** creates and initializes a new persistent task. */
public static TaskEntity createAndInsert(ActivityExecution execution) {
TaskEntity task = create();
task.insert((ExecutionEntity) execution);
return task;
}
public void insert(ExecutionEntity execution) {
CommandContext commandContext = Context.getCommandContext();
DbSqlSession dbSqlSession = commandContext.getDbSqlSession();
dbSqlSession.insert(this);
if(execution != null) {
execution.addTask(this);
}
commandContext.getHistoryManager().recordTaskCreated(this, execution);
}
/*
* 。。。。
*/
/** Creates a new task. Embedded state and create time will be initialized.
* But this task still will have to be persisted. See {@link #insert(ExecutionEntity)}. */
public static TaskEntity create() {
TaskEntity task = new TaskEntity();
task.isIdentityLinksInitialized = true;
task.createTime = ClockUtil.getCurrentTime();
return task;
}
由此知道,活动的时间是由ClockUtil.getCurrentTime()决定的。再来看看CockUtil的源码:
/**
* @author Joram Barrez
*/
public class ClockUtil {
private volatile static Date CURRENT_TIME = null;
public static void setCurrentTime(Date currentTime) {
ClockUtil.CURRENT_TIME = currentTime;
}
public static void reset() {
ClockUtil.CURRENT_TIME = null;
}
public static Date getCurrentTime() {
if (CURRENT_TIME != null) {
return CURRENT_TIME;
}
return new Date();
}
}
注意:
因为可能多线程情况,而且只有set,不会执行类似++,--这样的操作,所以这里用volatile关键字完全满足需要。
默认实现在分布式中问题
在上面介绍了DbIdGenerator以及ClockUtil之后,可以清楚明白他们的原理,那么在分布式部署中,如果还是使用这种默认的实现而不加以改善,会出现什么问题。
1.DbIdGenerator的getNextId()/getNewBlock()两个方法,在分布式主机中,synchronize不能顺利实现锁控制;
2.ClockUtil严重依赖容器所在服务器时间,但是分布式主机的时间不可能达到完全的同步;
3.在分布式主机中,对同一个任务,可以同时执行,因为他们都是DbSqlSession缓存,不会立马入库;也就是说,可能存在一个任务被同时自行两次的情况。
对1,2两点分析,基本上是确定会存在的,至于第三点,限于猜想,不知道实际是否有相关的解决策略,目前对activiti关于此处的设置猜想还没有完全弄清楚。
其实之所以那么在乎任务Id以及任务执行时间,主要是在流程跟踪图中,需要根据有序的历史任务结果集模仿重现走过的路径,而做到有序,这两个要素是非常关键的。
对分布式应用,如果同库,那ID的生成问题都会是一个问题,常见的解决方式是把他扔给数据库去解决,比如一个序列、一个类似序列的自定义函数等都是不错的选择。
当然,放到DB中以后,那么频繁访问数据库,activiti中设计的blocksize也就基本失效了,这个也算是衡量的结果吧。
实际问题分析
上述数据,是在生产上出现的问题数据,环境是为了负载均衡做了两个应用Server,同时连接一个DB;
从数据可以分析出“活动节点会在双机中运行”;
61011(A) >> 60852(B) >> 60866(B) >> 61022(A) >> 61028(A) >> 60889(B) >> 60893(B)
A机器上的61011执行完毕以后,事件如何转到B机器上的60852,这个还不明白,待解决!!