Yes, as long as it does not influence the parent token. That is why there are
some issues with some databases in the join at the moment, but these will be
solved (there already is a workaround)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4197791#4197791
anonymous wrote :
| I think, perhaps, my first post was a bit too abstract to be clear. So...
here is a more concrete example.
|
Thanks, that always helps
anonymous wrote : E(mail) will provide J(bpm) with delivery notification and
read receipt information via http callbacks.
| I hope
btw, you seem to do things synchronous in a transaction like way from E to J to
P. Is there a mechanism towards P if the 200 to E cannot be send? If not, why
not just do it async? I think/hope btw this is a minimal version of the process
to demonstrate your issue. Otherwise the added-value of
Ronald
Thanks for your answers. Am I right in thinking that two threads can, at the
same time:
1) load the same ProcessInstanceForUpdate
2) Signal to their different tokens
3) Close the context (and thus commit the changed process instance state back
to the database)
...without causing any
Ronald
I am fairly new to jBpm and am just looking for the appropriate jBpm way of
solving the problem.
I think, perhaps, my first post was a bit too abstract to be clear. So... here
is a more concrete example.
Lets envisage that jBpm (J) is responsible for escalating a problem with
external
jse I understand your problem. What I have done is to add process variable in y
process Instance to say of it's idle or not (in the wait state). If it's idle,
i fire the process else I persist this msg to be proceeded by the process when
previous message execution finish.
So that, the
Sorry... Adding processvariable to a processinstance to say it is idle (in
a waitstate) or not
Again.. this sounds like a really strange solution to an ever stranger
description... I think you misunderstand some concepts of jBPM, or I'm loosing
it... not sure which one it is..
AmiraTalbi
You exactly understand the problem... and you are right, it is not specifically
a jBpm issue. There is a resource (the process instance) that needs to be
used/updated by each thread in turn, not all at once.
The reason I did not want to use your suggestion is that I think that this
I had the same problematic. It's not a JBPM problem but a process state
consistency. I presume that you're receiving msg form asynchronous systems via
an MDB. In that case, you can change the PoolSize of that EJB to One, so that
it will proceed messages one by one.
Hope it will help
View
Guys please.. how does a random incomming message know how to signal
the process? You clearly do not state that. You say just signal the process.
Your example demonstrates that this is what you think you will do. What is the
advantage of having a process if any incoming message for
Each message should signal an individual token or task/state. There is no
problem with concurrency then. You should never signal the process in general.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4196691#4196691
Reply to the post :
11 matches
Mail list logo