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 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025379#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...