[jBPM Users] - Re: Hibernate, Sessions, and Sync - Oh my!
by MohReece
Michael, it looks like you're doing some custom asynchronous continuation, and the moment in which the new transaction is started (i.e. the jBPM context created) isn't related at all of the old transaction, which in a sense 'spawned' it - am I reading that correctly?
We have been doing something similar in our system (we're still using 3.1.4 for now, I guess you have a similar predicament in which upgrading an existing system just is easier said than done), and we encountered the same inconsistent and unpredictable SOSE occurrences.
The problem was that we used an indeterministic strategy for creating a new jBPM context in a new thread - we didn't wait for the old one to be closed and were 'hoping for the best' - unknowingly at first, of course.
We found a solution by making sure the new transaction is started only after the old one has ended: digging a little beyond the jBPM API into the Hibernate API, in which the org.hibernate.Transaction interface has the possibility to register a callback object (which must implement the javax.transaction.Synchronization interface). The latter object then is called before and after the two-phase-commit, and we used this last call as a starting point for the new transaction.
>From within an opened transaction we use something like this:
| jbpmContext.getSession().getTransaction().registerSynchronization(new Synchronization() {
| public void beforeCompletion() {
| // We're not using this one ourselves...
| }
|
| public void afterCompletion(int status) {
| // Here we spawn a new thread which can safely open its own jBPM context...
| }
| });
|
Hope this helps you out a little bit!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257185#4257185
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257185
16 years, 6 months
[jBPM Users] - Showing the process diagram in my own application
by sebastian.s
Hello,
regarding the process diagram I've got a couple of questions. The reason is that I am looking for a way to display the process diagram as shown in the console in my own application.
As far as I know the process diagram is not generated at runtime but during the designing of the process using the GPD in Eclipse. And the image is packed into the .bar-file and deployed together with the process definition.
How does the console put the red arrow at the right place in the image? Is the g-attribute also parsed and stored in the database when a process is deployed? If yes is this information accessible via the API? If not how does the console deals with this?
| ..
|
| <task assignee="mike" g="352,169,92,52" name="escalated">
| <transition g="-50,-21" name="to task2" to="task2"/>
| </task>
|
| ..
|
Thanks in advance!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257173#4257173
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257173
16 years, 6 months
[jBPM Users] - Re: Implementing Escalation in jBPM 4.1
by sebastian.s
I must be doing something wrong. I took the unit tests of the supplied examples as a base (regarding configuration files) which always worked fine for and I created my process and my tests. The problem is that an exception is thrown:
| 12:03:47,093 FIN | [ProcessDefinitionImpl] creating new execution for process 'escalation'
| 12:03:47,109 FIN | [DefaultIdGenerator] generated execution id escalation.1
| 12:03:47,234 FIN | [ExecuteActivity] executing activity(start1)
| 12:03:47,250 FIN | [DefaultIdGenerator] generated execution id escalation.1.timeout_task
| 12:03:47,406 FIN | [ExecutionImpl] created execution[escalation.1.timeout_task]
| 12:03:47,406 FIN | [ScopeInstanceImpl] creating timer on execution[escalation.1.timeout_task]
| ### EXCEPTION ###########################################
| 12:03:47,625 INF | [DefaultCommandService] exception while executing command org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd@694f12
| org.jbpm.api.JbpmException: no org.jbpm.pvm.internal.cal.BusinessCalendar in current environment
|
| <process name="escalation" xmlns="http://jbpm.org/4.0/jpdl">
| <start g="174,36,48,48" name="start1">
| <transition g="-106,-24" name="to timeout_task" to="timeout_task"/>
| </start>
| <task assignee="alex" g="152,168,92,52" name="timeout_task">
| <transition g="-50,-21" name="timeout" to="escalated">
| <timer duedate="5 seconds" />
| </transition>
| <transition g="-50,-21" name="to task2" to="task2"/>
| </task>
| <task assignee="mike" g="352,169,92,52" name="escalated">
| <transition g="-50,-21" name="to task2" to="task2"/>
| </task>
| <task assignee="peter" g="151,305,92,52" name="task2">
| <transition g="-48,-21" name="to end1" to="end1"/>
| </task>
| <end g="176,398,48,48" name="end1"/>
| </process>
|
| public void testTaskEscalaton() {
| ProcessInstance processInstance = executionService.startProcessInstanceByKey("escalation");
| String processInstanceId = processInstance.getId();
| processInstance = executionService.findProcessInstanceById(processInstanceId);
|
| List<Task> tasksAlex = taskService.findPersonalTasks("alex");
|
| if(tasksAlex.size() == 0) {
| fail();
| }
|
| Job job = managementService.createJobQuery()
| .timers()
| .processInstanceId(processInstance.getId())
| .uniqueResult();
|
| managementService.executeJob(job.getId());
| processInstance = executionService.findProcessInstanceById(processInstance.getId());
| assertTrue(processInstance.isActive("escalated"));
|
| List<Task> tasksMike = taskService.findPersonalTasks("mike");
| if(tasksMike.size() == 0) {
| fail();
| }
|
| tasksAlex = taskService.findPersonalTasks("alex");
| if(tasksAlex.size() == 1) {
| taskService.completeTask(tasksAlex.get(0).getId());
| } else {
| fail();
| }
|
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257169#4257169
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257169
16 years, 6 months
[jBPM Users] - Hibernate, Sessions, and Sync - Oh my!
by michaelholtzman
Greetings -
We are plagued with StaleObjectStateExceptions that I have been unable to resolve. We are running jBPM (derived from version 3.1.2) in an application which launches and manages our workflows and also executes commands targetting specific workflow instances (for example, a signal from our main application, an external system wrt the jBPM app).
We have a number of custom nodes that call out to our system and enter a wait state. Our system processes the request and sends back a command to the jbpm application. The command will include the process instance and token that made the request, and possibly data that will be saved in jbpm instance variables.
Our custom nodes use the JbpmContext attached to the current ExecutionContext. The 'out of band' command processing creates a new JbpmContext from a singleton JbpmConfiguration, loads the specified token by id and modifies it, then saves and closes the JbpmContext.
In general this works great, but I have one case that consistently causes SOSE's:
A custom node (Wait) creates a timer with a 10 second due date. When the timer fires, it transitions to a custom node (Script) that messages our system and goes into a wait state. Our system responds with a 'Results' command that essentially does this:
| gProcessInstance = jbpmContext.loadProcessInstance(gProcessInstanceId);
| if (gProcessInstance == null)
| throw new Exception("Unable to load process instance id " + gProcessInstanceId);
|
| if (gTokenId > 0) {
| gToken = jbpmContext.loadToken(gTokenId);
| } else {
| gToken = gProcessInstance.getRootToken();
| }
|
| // Get new JbpmContext from static configuration
| jbpmContext = Manager.jbpmConfiguration.createJbpmContext();
| try {
| // Set some instance variables
| ...
|
| // Save and close the jbpmContext
| jbpmContext.save(gToken);
| } catch (Exception e) {
| ...
| } finally {
| jbpmContext.close();
| }
|
Usually this works correctly, advancing the token from the 'Script' node to the next node in the process. However, sometimes the signal advances the token from the 'Wait' node -- the token's previous node. The next execution of jbpmContext.close() throws the SOSE.
My theory du jour is that somehow the transition in the workflow from 'Wait' to 'Script' has not been committed at the time the 'Result' command arrives, so that the loadToken() call is getting the state of the token before it moved to the 'Script' node and the Token.getNode() is returning the wrong node as the source of the transition.
I have tried adding
| jbpmContext.save(token);
| jbpmContext.getSession().flush();
|
when the 'Wait' and 'Script' nodes go into their respective wait states, as well as inserting
| jbpmContext.getSession().refresh(gToken)'
|
after loading the token, but the problem persists.
Any ideas?
Thanx.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257134#4257134
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257134
16 years, 6 months