-
1. Re: Un expected behavior observed with Token details
kukeltje Apr 23, 2007 4:14 AM (in response to narasimha_addanki)1: impossible, publish it somewhere and post the link
2: please state which jbpm version, which database, a unit test demonstrating the behaviour etc...etc...etc -
2. Re: Un expected behavior observed with Token details
malish May 23, 2007 10:31 PM (in response to narasimha_addanki)We have similar issues with getting a null token using call process.getRootToken(). It is fairly easy to achieve that:
* Define your own ActionHandler class. All it should do in execute(ctx) method, is throw new java.lang.Exception("haha")
* Place this ActionHandler into jpdl
* Invoke state transition by calling process.getRootToken().signal()
That would be the last moment when you are able to access rootToken. Next time process.getRootToken() will return NULL value. -
3. Re: Un expected behavior observed with Token details
malish May 23, 2007 10:39 PM (in response to narasimha_addanki)Just to correct the last sentence of my previous message:
process.getRootToken().getNode() will return NULL value.
Also, process.getRootToken().getAvailableTransitions() will start returning NULL value as well.
Not sure which how to check the JBPM version. Timestamp is 2007-03-16. -
4. Re: Un expected behavior observed with Token details
malish May 23, 2007 11:36 PM (in response to narasimha_addanki)Until an appropriate solution is found or reply is received from JBoss, we have just decided to apply the following local fix.
Again this is related to loss of Node after Exception is thrown within the custom ActionHandler.
All we do is saving the Node object before calling token.signal() method. When we catch the Exception and if new value of getNode() is NULL, we store the saved copy of the Node. Sample code is below:public void processWorkflowEvent(long pid, String eventName) throws ... { JbpmConfiguration jbpmConfiguration = JbpmConfiguration.getInstance(); JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext(); try { ... your own code ProcessInstance process = jbpmContext.getProcessInstanceForUpdate(pid); Token token = process.getRootToken(); // save the node Node nodeSaved = token.getNode(); // process signal try { token.signal(eventName); } catch(Exception e) { if(token.getNode() == null) { // node is lost due to JBPM internals // restore the node token.setNode(nodeSaved); } ... } } catch(Exception e) { // do whatever you need to handle own exceptions } finally { jbpmContext.close(); } }
-
5. Re: Un expected behavior observed with Token details
kukeltje May 24, 2007 4:07 AM (in response to narasimha_addanki)If you think this is a bug or enhancement, please file a jira issue. By just stating it here there is no guarantee it will get fixed
-
6. Re: Un expected behavior observed with Token details
estaub May 24, 2007 8:08 AM (in response to narasimha_addanki)malish,
When you jira it, you might ask for javadoc describing what to expect, regardless of the disposition of the request for a change in behavior. The current doc leaves it to your imagination.
-Ed -
7. Re: Un expected behavior observed with Token details
mputz May 24, 2007 8:12 AM (in response to narasimha_addanki)I could reproduce this with your suggestions of throwing an exception in an ActionHandler. But only if I signal this from a custom application, not from within the default jBPM 3.2 web app. So I suspect this is a configuration issue. I'll try to dig deeper and let you know when I find something...
-
8. Re: Un expected behavior observed with Token details
mputz May 24, 2007 8:29 AM (in response to narasimha_addanki)Please disregard my previous comment - it has nothing to do with configuration.
I oversaw that you were throwing an exception, but didn't mark the current transaction as to be rolled back.
So instead of your workaround of re-setting the node on the context again, just add jbpmContext.setRollbackOnly() in the catch block.public void processWorkflowEvent(long pid, String eventName) throws ... { JbpmConfiguration jbpmConfiguration = JbpmConfiguration.getInstance(); JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext(); try { ... your own code // process signal token.signal(eventName); } catch(Exception e) { // mark this transaction as dirty jbpmContext.setRollbackOnly(); // do whatever you need to handle own exceptions } finally { jbpmContext.close(); } }
No need for a JIRA entry IMO. -
9. Re: Un expected behavior observed with Token details
kukeltje May 24, 2007 9:06 AM (in response to narasimha_addanki)Would be nice to add a jira issue nevertheless. Just not for the original problem, but for adding this to the docs.
-
10. Re: Un expected behavior observed with Token details
estaub May 24, 2007 9:27 AM (in response to narasimha_addanki)Ronald,
Given what this turned out to be caused by, what are you thinking should be doc'd?
Maybe the getNode() return? Like so:@return the last node entered, or the start node for the root token of an unsignaled new process instance. Guaranteed non-null.
[I don't know for a fact that this is true, though... I'm just recording my own fantasy of how it works/should-work!]
-Ed Staub -
11. Re: Un expected behavior observed with Token details
kukeltje May 24, 2007 10:43 AM (in response to narasimha_addanki)Yes that to, but I was more thinking about the example Martin gave of the use of jBPMContext.setRolbackOnly()
-
12. Re: Un expected behavior observed with Token details
estaub May 24, 2007 12:24 PM (in response to narasimha_addanki)I suspect there are more problems here.
If I'm not mistaken, when an actionhandler is invoked, the transaction will have started at the last asynchronous event that caused something to be written persistently. If all the nodes are asynchronous, this is fine. But if there's a sequence of synchronous nodes, the process may unwind quite far back. This seems like it would be surprising to the developer. If any of the external actions in the rolled-back sequence aren't transactional, the process will now be "skewed", living in the past, relative to the real-world process being performed, probably waiting for an event that has already happened and now will never occur again.
If there are any actionhandlers or other elements that may or may not signal synchronously, the amount of rollback becomes somewhat unpredictable. This is common when waiting for an event that may have already happened, e.g., a timer that may have already expired.
I'm not saying that the JBPM internal process integrity is lost, just that the distance rolled back in the graph seems likely to be unexpected and/or uncertain, and hence difficult to design error-handling for.
Did I miss something? Is there an easy workaround? A best practice to propose?
-Ed Staub -
13. Re: Un expected behavior observed with Token details
kukeltje May 25, 2007 5:59 AM (in response to narasimha_addanki)Ed,
Your analysis is correct. These are common issues and have been discussed previously when talking about an 'undo' function.
Some issues/solutions have to modeled on the businesslevel. Others require a more technical approach. Do's /don'ts/best practices/common pitfalls are not really available yet. -
14. Re: Un expected behavior observed with Token details
estaub May 25, 2007 7:58 AM (in response to narasimha_addanki)Ronald,
Thanks for the feedback.
Transactions are never easy!
-Ed