[jboss-user] [jBPM] - Re: jPBM 5.1, persistent processes get finished without regard to session

Miljenko Norsic [http://community.jboss.org/people/mnorsic] created the discussion "Re: jPBM 5.1, persistent processes get finished without regard to session" To view the discussion, visit: http://community.jboss.org/message/628718#628718 -------------------------------------------------------------- Maciej, Jordi, thanks for the discussion. Personally, I think we need a freedom to do both things, because it is obvious that both scenarios are common. My point is that calling ksession.signalEvent(type, eventData); looks as one is trying to signal all process instances in a given knowledge session, but not in *all* knowledge sessions. It would be nicer to have something like this: ksession.signalEvent(type, eventData) - signals all processes in a given knowledge session ksession.signalEvent(type, eventData, processInstanceId) - signals all processes in a given knowledge session ksession.signalEvent(type, eventData, Collection<Long> processInstanceIds) - signals all processes with a given Id in a given knowledge session ksession.signalEvent(type, eventData, long processInstanceId) - signals process with a given id in a given knowledge session processInstance.signalEvent(type, eventData) - signals a particular process instance (the same as previous call) StatefulKnowledgeSession.signalEvent(type, eventData) - signals *all* processes that use this event type And of course, persistency model should be altered based on the API to reflect the changes. BTW, Jordi, can you ask you to share part of your process definition regarding wait states? I'm curious to see an alternative way of doing it by using a fact.... I have a situation where I have to implement a lot of "waiting nodes" that are going to decide whether to continue with processing, based on a fact that is going to be asserted every day (in some batch processing, for example). Right now I've developed two solutions: 1. custom work item node waiting for the right data to come - fact is part of my work item, and I don't think it will work as work item handlers are not persisted 2. calling signalEvent() to wake up waiting node to continue - I'm not happy with this solution as I have to have a number of intermediate catch events scattered through my process Is there a better way to wake up process? Did anyone created a custom work item handler that is registered to respond to signalEvent? Thanks, Miljenko -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/628718#628718] Start a new discussion in jBPM at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]