[jBPM Users] - Re: jBPM 4 and thread-safeness
by tom.baeyens＠jboss.com
good question/remark.
event listeners threadsafety in jbpm has a different meaning then threadsafe in general java. so therefor, we should indeed update the docs and not use the word threadsafe for it.
in strickt java sense, nutable methods on threadsafe objects should be synchronized. in jbpm sense, the only requirement is that you don't change your member fields in the execute method. setters of event handlers don't have to be synchronized as this is done during initialization before jbpm will use the object.
in jbpm 3, a new delegation object was instantiated *for every usage* of an action (event listener). in jbpm 4, we want to get to a situation that the event listener object becomes a part of the process definition object graph. and hence it gets cached and used by all threads.
hth
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254667#4254667
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254667
16 years, 7 months
[jBPM Users] - Re: workflow design about wait states
by mmusaji
Hi
Okay so here's my workflow.
| <?xml version="1.0" encoding="UTF-8"?>
|
| <process name="process" xmlns="http://jbpm.org/4.0/jpdl">
| <start>
| <transition to="parse request"/>
| </start>
|
| <custom class="org.application.workflow.ParseRequest" name="parse request" two="#{myObj}">
| <transition to="evaluate parse result"/>
| </custom>
|
| <decision name="evaluate parse result" expr="#{content}" >
| <transition name="valid" to="find providers" />
| <transition name="invalid" to="error"/>
| </decision>
|
| <custom two="#{myObj}" class="org.application.workflow.FindProviders" name="find providers">
| <transition to="fork"/>
| </custom>
|
| <fork name="fork">
| <transition name="validate one" to="validate one request"/>
| <transition name="validate two" to="validate two request"/>
| <transition name="validate three" to="validate three request"/>
| </fork>
|
| <!-- EACH OF THESE CUSTOM NODES WILL TAKE AN UNKNOWN AMOUNT OF TIME -->
| <custom continue="async" name="validate one request" class="org.application.workflow.ValidateoneFraudRequest" two="#{oneDetails}">
| <transition to="join"/>
| </custom>
|
| <custom continue="async" name="validate two request" class="org.application.workflow.ValidateExpFraudRequest" two="#{twoDetails}">
| <transition to="join"/>
| </custom>
|
| <custom continue="async" name="validate three request" class="org.application.workflow.ValidateSysFraudRequest" two="#{threeDetails}">
| <transition to="join"/>
| </custom>
|
| <!-- I WANT TO WAIT HERE UNTIL THEY ARE COMPLETE -->
| <state name="wait">
| <on event="fork">
| <event-listener class="org.application.workflow.WaitForValidation"/>
| </on>
| <transition to="join"/>
| </state>
|
| <join name="join" continue="exclusive">
| <transition name="to evaluate validation results" to="evaluate validation results"/>
| </join>
|
| <decision name="evaluate validation results" expr="#{content}" >
| <transition name="valid" to="construct message" />
| <transition name="invalid" to="error"/>
| </decision>
|
| <custom name="construct message" class="org.application.workflow.ConstructRequest" two="#{myObj}">
| <transition to="send"/>
| </custom>
|
| <custom name="send" class="org.application.workflow.SendRequest" two="#{myObj}">
| <transition to="get responses"/>
| </custom>
|
| <custom name="get responses" class="org.application.workflow.GetResponse" two="#{myObj}">
| <transition to="process responses"/>
| </custom>
|
| <custom name="process responses" class="org.application.workflow.ProcessResponse" two="#{myObj}">
| <transition to="getMyObject"/>
| </custom>
|
| <custom name="getMyObject" class="org.application.workflow.GetMyObject" two="#{myObj}">
| <transition to="end"/>
| </custom>
|
| <task name="end">
| <transition name="to complete" to="end process"/>
| </task>
|
| <end name="end process" state="complete"/>
| <end-error name="error"/>
|
| </process>
|
This is my WebMethod. This is what starts the process when a request is recieved and will give a better idea of what I'm trying to achieve. I hope.
@WebMethod
| public String request() {
| try {
| InitialContext ctx = new InitialContext();
| this.processEngine = (ProcessEngine)ctx.lookup("java:/ProcessEngine");
|
| ExecutionService execService = (ExecutionService)
| this.processEngine.get(ExecutionService.class);
|
| ProcessInstance processInstance = execService.startProcessInstanceByKey("process", variables);
|
| System.out.println("ProcessInstanceID: " + processInstance.getId());
| //we need a signal cos we have no idea how long the return from the providers will take in real life
| Thread.sleep(3000);
|
| //if I check this too early then I don't get the right details back
| oneDetails = (OneDetails)execService.getVariable(processInstance.getId(), "oneDetails");
| result = "OneDetails: " + oneDetails.getDetails();
|
| } catch (Exception e) {
| e.printStackTrace();
| }
|
Please explain further about signalling the specific state... which state? The one that is waiting for the processes in the fork to complete?
My Unit test which is attempting to signal the wait state is below. This isn't working at all at the moment.
| public void testSimple() throws Exception {
|
| ProcessInstance processInstance = executionService.startProcessInstanceByKey("process", variables);
| String processInstanceId = processInstance.getId();
|
| Execution waitExecution = processInstance.findActiveExecutionIn("wait");
| executionService.signalExecutionById(waitExecution.getId());
|
| OneDetails oneDetails = (OneDetails )executionService.getVariable(processInstanceId, "oneDetails ");
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254663#4254663
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254663
16 years, 7 months
[jBPM Users] - jBPM 4 and thread-safeness
by greeneagle
Hi,
I've been working for 2-3 years with jBPM 2/3 and now have the time to evaluate if I should switch to version 4 in future. In the user-guide I read the following:
anonymous wrote :
| For all objects that are referenced by a class name, will be instantiated during parsing time. Which implies that the objects have to be threadsafe. This is typically OK since those objects are typically immutable
|
In jBPM 3 an ActionHandler-Implementation was instantiated (lazy) at runtime. There was no need for an Action-impl to be threadsafe (and if several config-arguments were injected via processdefinition it wasn't for sure threadsafe :-). But although it was not threadsafe it was reusable - if an action was executed a second time (not concurrently) it was already instantiated.
But what is the difference in jBPM4 now? In a Java-Task for example it is still possible to provide arguments via declaration so this object (which is referenced by class-name) will never be threadsafe (except I chose the dirty way and make the variables final).
So my questions are:
Why do these objects have to be threadsafe? For me it doesn't make a difference if such a class is instantiated at parsing- or runtime.
If they must be threadsafe why are the classes in the examples not threadsafe
Why are objects instantiated (at parsing time) which maybe never will be used (who can guess the path of execution)?
Thanks in advance
regards,
Michael
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254605#4254605
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254605
16 years, 7 months