[edgarpoce]

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.

Does this make it any more clear (if you ignore the philosophical distractions)?

I guess it does, you tell me :)

thanks for your help

[edgarpoce]

hi rainer

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 reusable mdb calls to the action handler that find the meaning of life
3 - the action handler find the meaning of life
4 - the reusable mdb persist the process

has it any sense?

thanks in advance.
edgar

[ralfoeldi]

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 'retry'-transactions for the call back by the MDB etc. (As well as some other magic.)

Then I have a AbstractAsynchMDB that implements the onMessage() method, parses out all things relevant for the jBPM signalling and passes on the payload of the Message to the implementing class. This only has to call the callbackAsynch() method with a 'success', 'failure' or 'retry' constant and the base class takes care of the rest.

I have seperated all jBPM workflow code from the application code. The reason for this was seperating the transactions that contain the payload from the transactions that move the workflow. (If you persisted the processInstance in the payload MDB it would be all or nothing.) This basically means that ALL triggering of tokens happens by JMS and I only have a single MDB class (more than one instance) that exclusively accesses processInstances etc. So the 'meaning of live' MDB would send another Message back to the main jBPM MDB to signal the token.

Gee... this sounds complicated (now I have to ask: does this make sense?) but it realy isn't. Its all about correct transaction handling and works very nicely in practice.

As soon as I get around to checking out the 3.1 asynch stuff I'll see how the concepts fit.

Greetings

[edgarpoce]

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)

[ralfoeldi]

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 do check out the 3.1 asynch stuff. Koen posted the JBoss cvs so that should be accessable now.

Greetings

[edgarpoce]

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 :)

But do check out the 3.1 asynch stuff. Koen posted the JBoss cvs so that should be accessable now.

I downloaded the released version and I'm working with it, it will take me some time to test my app because there are a few api changes.

thanks,
edgar

[tom.baeyens]

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 we could create a new process language for defining multithreaded behaviour:
Each node in the graph could be associated with a plain command. A split and merge node could be introduced to spawn (and synchronize) multiple concurrent java threads. No persistence, no transactions, ...

It could be done. But i think it is another process language. In a second stage we could think about how to embed a piece of the multithreaded process language in e.g. jPDL...

regards, tom.

[dharraj]

Hello Rainer,

Another question regarding your comment

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 performed?

Thanks
Raj

FYI: I got the parallel fork woking using action handler that starts new thread to get the work done instead of JMS. Now I am trying to get the persistence in, but having some trouble.

[ralfoeldi]

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 problems. Even without the logs there are shared variables, etc.

=> Don't do it. Unless....

... you realy have divided your functionality so far that you concurrent threads have NO knowledge / access to the processInstance (this would have to be the case with a JMS solution to). Give the threads the information to do work and signal back (after acquiring a lock on the processInstance) But...

... if you would have done that you wouldn't get concurrency problems :-)

Now to the trivial: Hibernate uses "select for update" to acquire locks so the processInstance will be locked for the duration of your transaction. (You are running in defined transactions?)

Does that help?

Greetings

[dharraj]

Hello Rainer,

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 now.

All this works fine, I have not seen any problems. The problems I am having to do has to do with saving and retriving process instance, but nothing to do with threads. May be you can help me.

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, which it closes once it is done. The helper is used both by the main engine and the fork handler for saving process instance. When I try to save process instance from the engine using the helper, I get the following exception

java.lang.RuntimeException: couldn't save process instance 'org.jbpm.graph.exe.ProcessInstance@149a794'
org.hibernate.collection.AbstractPersistentCollection.setCurrentSession(AbstractPersistentCollection.java:410)
org.hibernate.event.def.OnUpdateVisitor.processCollection(OnUpdateVisitor.java:40)
org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:101)
org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:61)
org.hibernate.event.def.AbstractVisitor.processEntityPropertyValues(AbstractVisitor.java:55)
org.hibernate.event.def.AbstractVisitor.process(AbstractVisitor.java:123)
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performUpdate(DefaultSaveOrUpdateEventListener.java:267)
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsDetached(DefaultSaveOrUpdateEventListener.java:216)
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:93)
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl.java:520)
org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:513)
org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:509)
org.jbpm.db.GraphSession.saveProcessInstance(GraphSession.java:203)

My guess is that it has to do with the session that I opened in main, which is used to save process definition. You tell me.

Thanks
Raj

[ralfoeldi]

This

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 concurrency problem.

You have to open tx, lock on processInstance, do something, release processInstace, close tx. Anytime you try to change / access a processInstance in two or more session you have a problem. (You would have to let go of the processInstance before you start a thread and lock on it again(!) when you want to signal())

This isn't a jBPM problem anymore but a general concurrency problem where you have to get your threads, sessions and txs right.