concurrent issue in conversational aware actions.

[jeff.yuchang]

'jeff.yuchang' wrote:

parallel actions. (concurrency issue)
In the conversational ESB actions, the JBoss ESB didn't have a built-in concurrency mechanism that we can leverage to support our parallel actions. For example:
We have a message object, which can be called messageA. we want to deliver messageA to two different services simultaneously. Because in the messageA, it has associated its 'session' context. In each service, it probably update the 'session' context. This means we need to guarantee only one thread to update the 'session' context. At present, I didn't see any feature/mechanism that we can use in JBossESB, so we can only try to use the database's concurrency lock.

'objectiser' wrote:

On the concurrent issue (1), using the database is really the only way - as it is possible the session may receive multiple messages anyway, so these have to be dealt with in a synchronized manner. I imagine it may also be possible for the same service to be deployed in different clustered JBossESB environments, and therefore different events could be processed in different JBossESB environments - but synchronized through a central db.

[jeff.yuchang]

Yeah, if we really want to have mulitple threads, then we can only use database.

But it seems that some of them are not, such as Apache ODE Jacob.

Via Jacob, ODE represents the state of a BPEL process as a collection of objects (for lack of a more precise term) connected by channels for passing messages. In this context, a message is a lightweight, internal message -- just a Java type -- not the heavier WSDL messages that the engine sends and receives externally. When an object receives a message, it can create new channels and objects and send messages; concurrency is managed by consuming messages in a single-threaded fashion (on a per-process-instance basis).

It is from "http://www.infoq.com/articles/paul-brown-ode"

It seems jBPM also works this way, not sure at the moment, but it is a way that we can think about it.

[marklittle]

jBPM does everything through the database too.

I haven't looked at ODE for quite a while, but they're still using a single manager for the context. Whether that's maintained in the database or via some central service is really just an implementation issue (though persistence will still be needed in the latter case if we're to tolerate failures).

[jeff.yuchang]

jBPM does everything through the database too.

I need to look into jBPM deeply then. ;)