Ronald,
Thanks for the feedback.
Transactions are never easy!
-Ed
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4048661#4048661
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4048661
___
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 avai
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 synch
Yes that to, but I was more thinking about the example Martin gave of the use
of jBPMContext.setRolbackOnly()
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4048337#4048337
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=
Ronald,
Given what this turned out to be caused by, what are you thinking should be
doc'd?
Maybe the getNode() return? Like so:
anonymous wrote : @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 fo
Would be nice to add a jira issue nevertheless. Just not for the original
problem, but for adding this to the docs.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4048279#4048279
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=
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.setRollbac
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.
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
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4048242#
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
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4048163#4048163
Reply to the post :
http://www.jboss.com/index.html?module=bb&
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
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.
View the origin
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 tran
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
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039739#4039739
Reply to the post :
http://www.jbo
14 matches
Mail list logo
