Hi,
we are making electronic signing software which works like this: we create a form that needs to be signed by one or multiple signers. This initiates a signing process where we use Activiti. In our BPMN diagram we loop a list of persons which are sent email that they need to sign the form in a website. This is done as a multi-instance subprocess. We create a receive task for every signer and then wait that each of them has signed before we move on to archive the form.
For some reason we have noticed that if there are more than 64 signers (i.e. trying to create more than 64 instances in the multi-instance subprocess), Activiti actually exits the multi-instance subprocess and continues with the process which of course causes trouble:
SGN | ERROR | 2016-12-13 13:34:42,905 | pool-12-thread-1 | ExecuteAsyncRunnable | 264 - org.activiti.engine - 5.19.0 | Job 386384 failed
org.apache.ibatis.exceptions.PersistenceException:
### Error updating database. Cause: java.sql.SQLException: The DELETE statement conflicted with the REFERENCE constraint "ACT_FK_VAR_EXE". The conflict occurred in database "opsa-dev2_act", table "dbo.ACT_RU_VARIABLE", column 'EXECUTION_ID_'.
### The error may involve org.activiti.engine.impl.persistence.entity.ExecutionEntity.deleteExecution-Inline
### The error occurred while setting parameters
### SQL: delete from ACT_RU_EXECUTION where ID_ = ? and REV_ = ?
### Cause: java.sql.SQLException: The DELETE statement conflicted with the REFERENCE constraint "ACT_FK_VAR_EXE". The conflict occurred in database "opsa-dev2_act", table "dbo.ACT_RU_VARIABLE", column 'EXECUTION_ID_'.
at org.apache.ibatis.exceptions.ExceptionFactory.wrapException(ExceptionFactory.java:26)[270:org.mybatis.mybatis:3.2.8]
at org.apache.ibatis.session.defaults.DefaultSqlSession.update(DefaultSqlSession.java:154)[270:org.mybatis.mybatis:3.2.8]
at org.apache.ibatis.session.defaults.DefaultSqlSession.delete(DefaultSqlSession.java:165)[270:org.mybatis.mybatis:3.2.8]
at org.activiti.engine.impl.db.DbSqlSession$CheckedDeleteOperation.execute(DbSqlSession.java:293)[264:org.activiti.engine:5.19.0]
at org.activiti.engine.impl.db.DbSqlSession.flushRegularDeletes(DbSqlSession.java:922)[264:org.activiti.engine:5.19.0]
at org.activiti.engine.impl.db.DbSqlSession.flushDeletes(DbSqlSession.java:888)[264:org.activiti.engine:5.19.0]
at org.activiti.engine.impl.db.DbSqlSession.flush(DbSqlSession.java:613)[264:org.activiti.engine:5.19.0]
at org.activiti.engine.impl.interceptor.CommandContext.flushSessions(CommandContext.java:212)[264:org.activiti.engine:5.19.0]
at org.activiti.engine.impl.interceptor.CommandContext.close(CommandContext.java:138)[264:org.activiti.engine:5.19.0]
at org.activiti.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:66)[264:org.activiti.engine:5.19.0]
at org.activiti.engine.impl.interceptor.JtaTransactionInterceptor.execute(JtaTransactionInterceptor.java:65)[264:org.activiti.engine:5.19.0]
at org.activiti.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:31)[264:org.activiti.engine:5.19.0]
at org.activiti.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:40)[264:org.activiti.engine:5.19.0]
at org.activiti.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:35)[264:org.activiti.engine:5.19.0]
at org.activiti.engine.impl.asyncexecutor.ExecuteAsyncRunnable.run(ExecuteAsyncRunnable.java:69)[264:org.activiti.engine:5.19.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_21]
at java.lang.Thread.run(Thread.java:722)[:1.7.0_21]
Caused by: java.sql.SQLException: The DELETE statement conflicted with the REFERENCE constraint "ACT_FK_VAR_EXE". The conflict occurred in database "opsa-dev2_act", table "dbo.ACT_RU_VARIABLE", column 'EXECUTION_ID_'.
at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:372)[307:wrap_mvn_net.sourceforge.jtds_jtds_1.3.1:0.0.0]
at net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2988)[307:wrap_mvn_net.sourceforge.jtds_jtds_1.3.1:0.0.0]
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2421)[307:wrap_mvn_net.sourceforge.jtds_jtds_1.3.1:0.0.0]
at net.sourceforge.jtds.jdbc.TdsCore.getMoreResults(TdsCore.java:671)[307:wrap_mvn_net.sourceforge.jtds_jtds_1.3.1:0.0.0]
at net.sourceforge.jtds.jdbc.JtdsStatement.processResults(JtdsStatement.java:613)[307:wrap_mvn_net.sourceforge.jtds_jtds_1.3.1:0.0.0]
at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQL(JtdsStatement.java:572)[307:wrap_mvn_net.sourceforge.jtds_jtds_1.3.1:0.0.0]
at net.sourceforge.jtds.jdbc.JtdsPreparedStatement.execute(JtdsPreparedStatement.java:784)[307:wrap_mvn_net.sourceforge.jtds_jtds_1.3.1:0.0.0]
at org.apache.ibatis.executor.statement.PreparedStatementHandler.update(PreparedStatementHandler.java:44)[270:org.mybatis.mybatis:3.2.8]
at org.apache.ibatis.executor.statement.RoutingStatementHandler.update(RoutingStatementHandler.java:69)[270:org.mybatis.mybatis:3.2.8]
at org.apache.ibatis.executor.SimpleExecutor.doUpdate(SimpleExecutor.java:48)[270:org.mybatis.mybatis:3.2.8]
at org.apache.ibatis.executor.BaseExecutor.update(BaseExecutor.java:105)[270:org.mybatis.mybatis:3.2.8]
at org.apache.ibatis.executor.CachingExecutor.update(CachingExecutor.java:71)[270:org.mybatis.mybatis:3.2.8]
at org.apache.ibatis.session.defaults.DefaultSqlSession.update(DefaultSqlSession.java:152)[270:org.mybatis.mybatis:3.2.8]
... 16 more
So what could cause Activiti exiting from the multi-instance subprocess if there are lots of instances?
I've never seen this issue before. Could you please share your bpmn xml (or a simplified version) along with a unit test where I can easily reproduce the issue?
Cheers,
Ciju
The only thing I can think of is that the exception isn't actually tied to 64 instances, but that this is simply where other factors become relevant (i.e. DB lock duration etc).
I expect you are setting or perhaps deleting a process variable inside your multi instance service which is what is causing the constraint violation.
Try using called activity to handle the signing messaging, this way you can isolate the process vars away from the main (calling) process.
Cheers,
Greg
Ask for and offer help to other Alfresco Process Services and Activiti Users and members of the Alfresco team.
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.