"roschmel" wrote : So in an ideal world you would exactly know where the process
execution has crashed. This would mean committing every little step - but this is not
really cool stuff.....
|
this is what we call a transactional script.
this is where jpdl is exactly suited for. see async="true". you can have the
commit after every step.
"roschmel" wrote : So its first about knowing where the process have crashed -
therefore you need logging information - just another topic I am currently discussing in
the user forum.
|
no logging information is irrelevant. you need to map how you want java exceptions to
affect the progress of your process.
for each potential failure of non transactional resources you need to decide : either the
process continues or the process execution rolls back till the last committed point of
execution.
"roschmel" wrote :
| And its about minimizing the chance, that a jBPM Transaction is getting rolled back.
It is espacially about not considering a rollback as "a normal path of
execution" - a rollback is for really bad things happended and not per design. So I
think SOSE and retrying as a designed path of execution is simply wrong.
|
then i think you didn't get it yet.
"roschmel" wrote :
| What I would expect:
| If I have a process 1 waiting in state-A and waiting in state-B for the callback from
an external system and both of them sending me the signal at the same time, I expect to
have them executed just one after the other and I do not expect getting exception and
letting the engine doing things twice.
|
this makes sense ! i didn't think if this use case yet.
should be really simple to get this one going. as we already have the exclusive job
execution. that means that you can mark async messages or timers as being exclusive.
first, you have to make sure that all the progress in the process is made by the job
executor. this would be possible to use the async command service. then you need to make
sure that the async command service would set the exclusive flag to true.
then you need to make sure that all other jobs that are created in this process also set
this exclusive flag to true.
good point!
we have all the infrastructure in place to make sure that we also cover this use case.
i'll keep that in mind and hopefully this is fully documented by jbpm 4.0.0.GA
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207774#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...