This
anonymous wrote : I have one jbpmSession that I open that is used in the main
class (the engine) only and it stays open till the process instance completes
(normally or abnormally). I also have a helper application that opens its own
jbpmSession to save process instance,
is your
Hi Raj,
quick answer to the threads: don't do it. It won't work. Never, ever.
This has been discussed in several threads.
Executing workflows writes logs, logs are on a processInstance level.
Concurrently executing causes concurrent writes to the processInstance =
causes persistence
Hello Rainer,
anonymous wrote : you realy have divided your functionality so far that you
concurrent threads have NO knowledge
The threads do not have any knowledge of any jBPM stuff. They simply run what
ever they are asked to and when completed notifies the waiting thread that it
can signal
Hello Rainer,
Another question regarding your comment
anonymous wrote : GraphSession has a lockProcessInstance() method that will
lock by way oh database
How can I use this method to do concurrent process instance persistence and
token.signal? Also, is the lock released once the update is
jPDL focusses on the state machine / transaction / persistence mechanics of
workflow and BPM. And this is definitely different from multithreaded
programming.
Lately i have been thinking about it in the context of Graph Oriented
Programming (jbpm.org/gop) and i'm starting to be convinced that
Hi Rainer
Thanks for sharing the concept. If it's ok with you I'd like see the code,
would you share it?. Of course If I find any improvement or change, I'll be
happy to send it back.
br,
edgar (edgarpoce AT gmail DOT com)
View the original post :
Edgar,
that's not my decision to make. I was going to ask the company here what their
opinion on open sourcing elements is anyway.
The alternative would be a clean room implementation, which wouldn't be too
hard either. Both (asking officially or clean room) will take at least 1-2
weeks.
But
anonymous wrote : that's not my decision to make. I was going to ask the
company here what their opinion on open sourcing elements is anyway.
don't worry, I had to ask :)
anonymous wrote : But do check out the 3.1 asynch stuff. Koen posted the JBoss
cvs so that should be accessable now.
I
Hi rainer
the actionhandler that sends the JMS message and the MDB that find the meaning
of life seem to be reusable. If I'm not missing something, that's the kind of
support that I'd like to see included in JBPM, maybe as a new node type.
anonymous wrote : Does this make it any more clear
hi rainer
anonymous wrote : and the MDB that find the meaning of life seem to be reusable
I assume that the MDB delegates to another action handler the responsibility of
finding the meaning of life.
e.g. when the token arrives:
1 - the reusable action handlers sends a message.
2 - the
Hi Edgar,
if we have a MDB that finds the meaning of life, well... we just might not need
any beans at all anymore. Who knows :-))
What I have is an AbstractAsynchActionHandler that is configable for all kinds
of stuff. Should the node wait for MDB to complete, 'success'-, 'failure'- and
Hello Rainer
| correct, you will not achieve true Java concurrency with a fork
|
Are their any plans to enable this? If so, do you roughly know when?
Thanks
Raj
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3923412#3923412
Reply to the post :
Hi Raj,
check out the various threads on this subject. This has been discussed in
extreme detail.
As I mentioned there are good reasons not to spawn threads. One would be that
you are simply not allowed to do so in a J2EE environment. The others lie in
the concept and implementation details
hi Rainer
anonymous wrote : So my answer to your question is another question: what is
the use case for Java concurrency in jBPM?
Another use case for the record ;). I'm using jbpm to manage a billing system.
The billing process involves not only human interaction but also time consuming
Hi Edgar,
I would like to understand this one.
Doesn't szenario b) do the trick? Executing whatever long running task you have
asynchronously by way of JMS or jBPM 3.1?
Then you would only have to lock on the processInstance for the short time you
need to update variables and trigger a
hi
anonymous wrote : Doesn't szenario b) do the trick? Executing whatever long
running task you have asynchronously by way of JMS or jBPM 3.1?
I didn't know about the new feature in 3.1, I'll take a look at it asap.
thanks for the tip.
Even when I could manage to roll my own jms stuff I
Hello All,
Let me mention this again and as clearly as I can, I am trying to model an
existing process (application) pipeline using the JBPM. The input(s) to the
next stage (application) in pipeline is output from previous stage. There are
stages that requires multiple input(s) which are
Hi Raj,
you do the split
| ForkA
|
| StateA1 StateA2
| (sends JMS (sends JMS
| and waits) and waits)
|
|
Hi Raj,
correct, you will not achieve true Java concurrency with a fork. This is
discussed in some detail in various Threads here. There are some very good
reasons for jBPM not to start threads.
jBPM implements concurrency in a business process sense, not in a Java
multithreading sense. This
Thanks Rainer.
If the process instance persistence and token signal are both synchronized over
process instance, I will not achieve a truely parallel fork, right?
Raj
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3922993#3922993
Reply to the post :
Raj,
as I just stated in the other thread you will have to lock on processInstance.
What seems to be happening here is that some other thread is doing something
that creates logs. If you take a look at the code you'll see:
| void saveLogs(ProcessInstance processInstance) {
|
Hello Rainer
Do you mean locking on process instance in this method or everywhere the
process instance is used? Because my original code was doing just that, as
follows:
| public static void persistPI(ProcessInstance pi)
| throws Exception
| {
| synchronized(pi) {
|
Hello Rainer,
I think I have the answer to my following question.
anonymous wrote : Does 'token.signal()' change process log list?
I have the fix and it works. Thanks
Raj
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3922396#3922396
Reply to the post :
Hello Rainer,
Here is how I understand the problem, see if I am correct.
I have one thread that is saving the process instance, which results in the
call to the saveLogs. The saveLogs traverses pi's log list using the iterator.
Meanwhile another thread calls token.signal(), which causes a new
Right on.
Basically every non-read access to any element of a processInstance should be
inside of a lock on the processInstance.
Logs are written, variables set, etc. etc. There are many reasons why this is
required.
You cannot however use synchronized(). This locks on the Java Object, not on
25 matches
Mail list logo
