Setting Process Variable after complete: Process does nit finish correctly.

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-16-2013 06:20 AM
Hello,
We have a process, that finishes with a service task (db update).
[img]http://abload.de/img/capturedzrhx.png[/img]
In there, we used runtimeService.setVariable(); to set another variable, if the database update was successfull or not.
(this method is called by the service task):
This causes the following problem:
When the process is completed, he is shown as RUNNING and Completed. (i.e. both, the historicService and the runtimeService are returning this process, when using the processQuery)
We noticed the following database inconsistences are generated:
- Activitii dropped ALL Variables from the ACT_RU_VARIABLE, except the one that has been set above. (dbUpdated)
(I assume, that activiti IS flushing all the variables, and - while completing the transaction - creating the value.
- Activiti setup the start- and endevent in ACT_HI_EXECUTION correctly.
- Activiti did NOT delete everything from ACT_RU_EXECUTION. *
*In the log files we found that activiti was unable to delete the running execution, because the foreign key constraint with the ru_variable table failed:
We have a process, that finishes with a service task (db update).
[img]http://abload.de/img/capturedzrhx.png[/img]
In there, we used runtimeService.setVariable(); to set another variable, if the database update was successfull or not.
(this method is called by the service task):
public void updateContractEntity() throws RESTOperationFailedException, ReservedValueUsedException { // Post changes back to EntityStore. log.f(getClass(), "Updating Contract Entity in EntityStore."); EntityAdapter ea = null; try { ea = new EntityAdapter(oceProcessService.getProcessKey(businessProcess.getProcessInstance())); ea.update("contract", processVariableMap, new Date()); runtimeService.setVariable(businessProcess.getProcessInstance().getProcessInstanceId(), "dbUpdated", true); } catch (ConfigurationException e) { // Rethrow. throw new RESTOperationFailedException(e); } }
This causes the following problem:
When the process is completed, he is shown as RUNNING and Completed. (i.e. both, the historicService and the runtimeService are returning this process, when using the processQuery)
We noticed the following database inconsistences are generated:
- Activitii dropped ALL Variables from the ACT_RU_VARIABLE, except the one that has been set above. (dbUpdated)
(I assume, that activiti IS flushing all the variables, and - while completing the transaction - creating the value.
- Activiti setup the start- and endevent in ACT_HI_EXECUTION correctly.
- Activiti did NOT delete everything from ACT_RU_EXECUTION. *
*In the log files we found that activiti was unable to delete the running execution, because the foreign key constraint with the ru_variable table failed:
### Error updating database. Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Cannot delete or update a parent row: a foreign key constraint fails (`oce2`.`ACT_RU_VARIABLE`, CONSTRAINT `ACT_FK_VAR_EXE` FOREIGN KEY (`EXECUTION_ID_`) REFERENCES `ACT_RU_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_ = ?### Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Cannot delete or update a parent row: a foreign key constraint fails (`mydb`.`ACT_RU_VARIABLE`, CONSTRAINT `ACT_FK_VAR_EXE` FOREIGN KEY (`EXECUTION_ID_`) REFERENCES `ACT_RU_EXECUTION` (`ID_`)) at org.apache.ibatis.exceptions.ExceptionFactory.wrapException(ExceptionFactory.java:23) at org.apache.ibatis.session.defaults.DefaultSqlSession.update(DefaultSqlSession.java:147) at org.apache.ibatis.session.defaults.DefaultSqlSession.delete(DefaultSqlSession.java:158) at org.activiti.engine.impl.db.DbSqlSession$DeleteById.execute(DbSqlSession.java:146) at org.activiti.engine.impl.db.DbSqlSession.flushDeletes(DbSqlSession.java:483) at org.activiti.engine.impl.db.DbSqlSession.flush(DbSqlSession.java:371) at org.activiti.engine.impl.interceptor.CommandContext.flushSessions(CommandContext.java:157) at org.activiti.engine.impl.interceptor.CommandContext.close(CommandContext.java:109) at org.activiti.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:49) at org.activiti.engine.impl.interceptor.JtaTransactionInterceptor.execute(JtaTransactionInterceptor.java:59) at org.activiti.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:33) at org.activiti.engine.impl.TaskServiceImpl.complete(TaskServiceImpl.java:148) at org.activiti.cdi.BusinessProcess.completeTask(BusinessProcess.java:350) at my.namespace.controller.TaskViewController.completeTask(TaskViewController.java:268) at my.namespace.controller.TaskViewController$Proxy$_$$_WeldClientProxy.completeTask(TaskViewController$Proxy$_$$_WeldClientProxy.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.el.parser.AstValue.invoke(AstValue.java:262) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278) at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:39) at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88) at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) at javax.faces.component.UICommand.broadcast(UICommand.java:315) at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259) at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:77) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) at org.togglz.servlet.TogglzFilter.doFilter(TogglzFilter.java:58) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61) at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108) at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137) at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125) at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66) at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449) at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365) at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90) at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83) at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:380) at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362) at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) at my.namespace.filters.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:91) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) at my.namespace.filters.EncodingFilter.doFilter(EncodingFilter.java:17) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) at my.namespace.filters.NoCacheFilter.doFilter(NoCacheFilter.java:21) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) at java.lang.Thread.run(Thread.java:662)Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Cannot delete or update a parent row: a foreign key constraint fails (`mydb`.`ACT_RU_VARIABLE`, CONSTRAINT `ACT_FK_VAR_EXE` FOREIGN KEY (`EXECUTION_ID_`) REFERENCES `ACT_RU_EXECUTION` (`ID_`)) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at com.mysql.jdbc.Util.handleNewInstance(Util.java:407) at com.mysql.jdbc.Util.getInstance(Util.java:382) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1040) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3603) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3535) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1989) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2150) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2626) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119) at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1362) at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.execute(WrappedPreparedStatement.java:404) at org.apache.ibatis.executor.statement.PreparedStatementHandler.update(PreparedStatementHandler.java:41) at org.apache.ibatis.executor.statement.RoutingStatementHandler.update(RoutingStatementHandler.java:66) at org.apache.ibatis.executor.SimpleExecutor.doUpdate(SimpleExecutor.java:45) at org.apache.ibatis.executor.BaseExecutor.update(BaseExecutor.java:108) at org.apache.ibatis.executor.CachingExecutor.update(CachingExecutor.java:75) at org.apache.ibatis.session.defaults.DefaultSqlSession.update(DefaultSqlSession.java:145) … 77 more
Labels:
- Labels:
-
Archive
7 REPLIES 7
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-20-2013 08:35 AM
Do you have an isolated unit-test for this that can be run easily standalone with the configuration you're using? As this is quite trivial behaivour (saving variables), we have a lot of coverage for these kind of things. Could be that a specific configuration OR operation( or the moment you do it) is causing this issue.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-22-2014 05:26 PM
We're having a similar issue that seems to be related to ACT-955:
<code>
### Error updating database. Cause: java.sql.SQLIntegrityConstraintViolationException: ORA-02292: integrity constraint (ACTIVITI.ACT_FK_VAR_EXE) violated - child record found
### 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.SQLIntegrityConstraintViolationException: ORA-02292: integrity constraint (ACTIVITI.ACT_FK_VAR_EXE) violated - child record found
</code>
It seems to be related to having duplicate variables in ACT_RU_VARIABLE (note the REV is incremented):
2070893 2 string rootProcessDefinitionKey 1796751 1796751
2068451 1 string rootProcessDefinitionKey 1796751 1796751
After deleting one of these, we can complete the workflows…but I can't figure out how these dups are being created. We use the REST API for all of our Activiti integration. We've also only seen this issue in our production environment, which is 5.14. Any ideas?
<code>
### Error updating database. Cause: java.sql.SQLIntegrityConstraintViolationException: ORA-02292: integrity constraint (ACTIVITI.ACT_FK_VAR_EXE) violated - child record found
### 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.SQLIntegrityConstraintViolationException: ORA-02292: integrity constraint (ACTIVITI.ACT_FK_VAR_EXE) violated - child record found
</code>
It seems to be related to having duplicate variables in ACT_RU_VARIABLE (note the REV is incremented):
2070893 2 string rootProcessDefinitionKey 1796751 1796751
2068451 1 string rootProcessDefinitionKey 1796751 1796751
After deleting one of these, we can complete the workflows…but I can't figure out how these dups are being created. We use the REST API for all of our Activiti integration. We've also only seen this issue in our production environment, which is 5.14. Any ideas?
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-22-2014 05:49 PM
Didn't make it all the way through the forum search results before posting…my bad. Looks like this was resolved in 5.15 under ACT-1887. I can't think of any place where we'd update a variable in separate threads, but somehow that is happening. Since the fix is in setting the variables, we'll need to manually delete all of the dups from the table after the upgrade…correct?
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-24-2014 03:32 AM
> Since the fix is in setting the variables, we'll need to manually delete all of the dups from the table after the upgrade…correct?
Yes, it does seem like it unfortunately.
One thing to verify is that it works on 5.15.1, before doing the production upgrade. especially if you are mentioning that you aren't using multiple threads on the same process
Yes, it does seem like it unfortunately.
One thing to verify is that it works on 5.15.1, before doing the production upgrade. especially if you are mentioning that you aren't using multiple threads on the same process
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-24-2014 02:22 PM
We are planning to change the ACT_FK_VAR_EXE constraint to cascade deletes. Not sure why I didn't think about this before. That should get us up and running on 5.14 without the risk of rushing an upgrade outside of a release cycle, and we also won't have to worry about deleting the dups.
Regarding multipe threads…we are using execution listeners for setting a couple of variables on Start (rootProcessDefinitionKey and rootProcessInstanceId). We use subprocesses/call activities extensively, and as variable names imply, this allows us to see what the base workflow is from the child process. Since both the base workflow and the subprocess use the listener, we may be getting dups if the variable is set on both process instances before the first commit point. The strange thing is that we can't recreate the problem in any pre-production environment (on either 5.14 or 5.15.1). The only way to force the constraint violation is to manually insert the duplicate variables in the table.
Anyways, regardless of how the dups are being set (and whether or not it's fixed in 5.15.1), the cascading delete should resolve the issue. Once we're on 5.15.1 in production, I will check to see if we're still getting runtime variable dups and report back.
Regarding multipe threads…we are using execution listeners for setting a couple of variables on Start (rootProcessDefinitionKey and rootProcessInstanceId). We use subprocesses/call activities extensively, and as variable names imply, this allows us to see what the base workflow is from the child process. Since both the base workflow and the subprocess use the listener, we may be getting dups if the variable is set on both process instances before the first commit point. The strange thing is that we can't recreate the problem in any pre-production environment (on either 5.14 or 5.15.1). The only way to force the constraint violation is to manually insert the duplicate variables in the table.
Anyways, regardless of how the dups are being set (and whether or not it's fixed in 5.15.1), the cascading delete should resolve the issue. Once we're on 5.15.1 in production, I will check to see if we're still getting runtime variable dups and report back.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-25-2014 04:04 AM
> We are planning to change the ACT_FK_VAR_EXE constraint to cascade deletes.
Good thinking.
> Once we're on 5.15.1 in production, I will check to see if we're still getting runtime variable dups and report back.
Great. Looking forward to no dups 🙂
Good thinking.
> Once we're on 5.15.1 in production, I will check to see if we're still getting runtime variable dups and report back.
Great. Looking forward to no dups 🙂
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-10-2014 09:48 AM
Joram,
Can you please confirm if this issue is fixed in 15.5.1 .
Can you please confirm if this issue is fixed in 15.5.1 .
