"estaub" wrote : Tom, | | I think this is another case, like the one a month or so ago with ProcessInstances not existing when needed that I tried to help with, where additional database commits are necessary. | | In this case, the commit must be somewhere in the flow of execution between: | | In TaskInstance: | public void setActorId(String actorId, boolean overwriteSwimlane){ | | // do the actual assignment | | this.previousActorId = this.actorId; | | this.actorId = actorId; | | if ( (swimlaneInstance!=null) | | && (overwriteSwimlane) ) { | | log.debug("assigning task '"+name+"' to '"+actorId+"'"); | | swimlaneInstance.setActorId(actorId); | | } | | COMMIT AFTER HERE... | | | | and in GraphElement: | void executeActions(List actions, ExecutionContext executionContext, boolean isPropagated) { | | if (actions!=null) { | | Iterator iter = actions.iterator(); | | while (iter.hasNext()) { | | Action action = (Action) iter.next(); | | if ( action.acceptsPropagatedEvents() | | || (!isPropagated) | | ) { | | if (action.isAsync()) { | | Message continuationMsg = new ExecuteActionCommand(action, executionContext.getToken()); | | MessageService messageService | | = (MessageService) Services.getCurrentService(Services.SERVICENAME_MESSAGE); | | COMMIT BEFORE HERE: | | messageService.send(continuationMsg); | | | | Because the next instruction executed after the send may be in the other thread - you haven't committed yet, I don't think. | | An efficient implementation would be to keep an internal queue of messages to send after you've committed, before you enter a wait state. This would avoid any additional commits, and I think it would preserve the correct semantics. | | I easily may be overlooking something - I don't know this code anywhere near as well as you, of course! | | -Ed Staub the idea is that there should never be a persistence operation during process execution. always, when you are in a wait state, that is when you can save your process. regarding the async message, you are right if you use the default JMS configurations. in which case, the message sending is committed before the send method returns. but you should use/configure your async message service so that it takes part in the same transaction as the jbpm updates. in the POJO configuration of jbpm, this is done by making sure that the message service operates on the same JDBC connection as the jbpm persistence sessions. i don't get the task instance example you give. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025436#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...