[Design of JBoss jBPM] - Re: jBPM Multithreading: Is there a specification?
by tom.baeyens＠jboss.com
"archer77" wrote :
| BTW: My setup is a standalone jBPM (with in-memory sql database), no ejbs, jboss container, ..
a transient usage of jBPM is a whole other story.
jBPM is usable in transient mode. you don't even have to use an in memory db in that case. you can just parse your process definitions and create new instances of ProcessInstance for it, and then execute those.
but for that scenario, we don't have the right forks and joins yet. in such situations, you should use a different kind of fork and join behaviour, based on multithreading. we don't have that yet.
the simplest way to get that non-persistent runtime concurrency behaviour is by just using the current forks and joins, but writing your own MessageService. Then you can leverage async="true" and your async message executor will generate multiple concurrent threads.
Later, we might actually create a new process language for non persisted multi threaded processes.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025445#4025445
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025445
19 years, 1 month
[Design of JBoss jBPM] - Re: jBPM Multithreading: Is there a specification?
by tom.baeyens＠jboss.com
"estaub" wrote : Tom,
|
| I think this is another case, like the one a month or so ago with ProcessInstances not existing when needed that I tried to help with, where additional database commits are necessary.
|
| In this case, the commit must be somewhere in the flow of execution between:
|
| In TaskInstance:
| public void setActorId(String actorId, boolean overwriteSwimlane){
| | // do the actual assignment
| | this.previousActorId = this.actorId;
| | this.actorId = actorId;
| | if ( (swimlaneInstance!=null)
| | && (overwriteSwimlane) ) {
| | log.debug("assigning task '"+name+"' to '"+actorId+"'");
| | swimlaneInstance.setActorId(actorId);
| | }
| | COMMIT AFTER HERE...
| |
|
| and in GraphElement:
| void executeActions(List actions, ExecutionContext executionContext, boolean isPropagated) {
| | if (actions!=null) {
| | Iterator iter = actions.iterator();
| | while (iter.hasNext()) {
| | Action action = (Action) iter.next();
| | if ( action.acceptsPropagatedEvents()
| | || (!isPropagated)
| | ) {
| | if (action.isAsync()) {
| | Message continuationMsg = new ExecuteActionCommand(action, executionContext.getToken());
| | MessageService messageService
| | = (MessageService) Services.getCurrentService(Services.SERVICENAME_MESSAGE);
| | COMMIT BEFORE HERE:
| | messageService.send(continuationMsg);
| |
|
| Because the next instruction executed after the send may be in the other thread - you haven't committed yet, I don't think.
|
| An efficient implementation would be to keep an internal queue of messages to send after you've committed, before you enter a wait state. This would avoid any additional commits, and I think it would preserve the correct semantics.
|
| I easily may be overlooking something - I don't know this code anywhere near as well as you, of course!
|
| -Ed Staub
the idea is that there should never be a persistence operation during process execution.
always, when you are in a wait state, that is when you can save your process.
regarding the async message, you are right if you use the default JMS configurations. in which case, the message sending is committed before the send method returns. but you should use/configure your async message service so that it takes part in the same transaction as the jbpm updates. in the POJO configuration of jbpm, this is done by making sure that the message service operates on the same JDBC connection as the jbpm persistence sessions.
i don't get the task instance example you give.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025436#4025436
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025436
19 years, 1 month
[Design of JBoss ESB] - Re: jBPM in JBossESB
by bill.burke＠jboss.com
"rex.sheridan" wrote : On a related note, I was wondering the other day about the following: what if someone were to implement an ESB gateway using a jBPM process. You could basically have a long running process and send it a "poll" signal at some interval. I wonder if it would be useful.
|
| I've been thinking in jBPM mode for so long I've started finding all sorts of uses for it :)
Not only that, but you could have the ESB message be put in a wait state while it was waiting for some external system to respond. You could have timers fire off. It just seems like there's so much you could do if the two were combined into one metamodel. Combine ESB's rich component set, with JBPMs clean process model.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025406#4025406
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025406
19 years, 1 month
[Design of JBoss jBPM] - Re: jBPM Multithreading: Is there a specification?
by archer77
"tom.baeyens(a)jboss.com" wrote : in a persistent environment, jBPM synchronizes on the database.
What behaviour should I expect in this case? I would expect that a select on a table where a write-transaction from another thread is open should block until the transaction is ended (It might also throw something like a ConcurrentAccessException to indicate the access conflict).
Looking at my problem, this should cause the second thread to block until the first transaction is commited, but instead second thread is not block (or receives an "concurrent access exception"), which I would expect, instead it returns data (directly from the DB?) which conflicts with data held in another thread (out of sync data).
anonymous wrote :
| you'll get your concurrency from your environment (ejbs, mdbs, web app and the likes) note that when moving transactional from one wait state to the next, jBPM synchronizes on the DB, so transactions should be handled concurrently, but inside one transaction, no multi threading is needed.
Does that mean that the jBPM keeps one transaction open from ending one task until wait() in the next task? Will an error in task-assign also rollback the task-end (node-leave) of the previous node?
And when is the task-assign event handling triggered?
I assumed that the first transaction (Thread A) should be ended before sending the events (because the event handlers already receive a fixed task assignment). The event actions then would have to create more transactions if they need them, but the task instance assignment
BTW: My setup is a standalone jBPM (with in-memory sql database), no ejbs, jboss container, ..
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025387#4025387
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025387
19 years, 1 month
[Design of JBoss jBPM] - Re: jBPM Multithreading: Is there a specification?
by estaub
Tom,
I think this is another case, like the one a month or so ago with ProcessInstances not existing when needed that I tried to help with, where additional database commits are necessary.
In this case, the commit must be somewhere in the flow of execution between:
In TaskInstance:
public void setActorId(String actorId, boolean overwriteSwimlane){
| // do the actual assignment
| this.previousActorId = this.actorId;
| this.actorId = actorId;
| if ( (swimlaneInstance!=null)
| && (overwriteSwimlane) ) {
| log.debug("assigning task '"+name+"' to '"+actorId+"'");
| swimlaneInstance.setActorId(actorId);
| }
| COMMIT AFTER HERE...
|
and in GraphElement:
void executeActions(List actions, ExecutionContext executionContext, boolean isPropagated) {
| if (actions!=null) {
| Iterator iter = actions.iterator();
| while (iter.hasNext()) {
| Action action = (Action) iter.next();
| if ( action.acceptsPropagatedEvents()
| || (!isPropagated)
| ) {
| if (action.isAsync()) {
| Message continuationMsg = new ExecuteActionCommand(action, executionContext.getToken());
| MessageService messageService
| = (MessageService) Services.getCurrentService(Services.SERVICENAME_MESSAGE);
| COMMIT BEFORE HERE:
| messageService.send(continuationMsg);
|
Because the next instruction executed after the send may be in the other thread - you haven't committed yet, I don't think.
An efficient implementation would be to keep an internal queue of messages to send after you've committed, before you enter a wait state. This would avoid any additional commits, and I think it would preserve the correct semantics.
I easily may be overlooking something - I don't know this code anywhere near as well as you, of course!
-Ed Staub
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025379#4025379
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025379
19 years, 1 month
[Design the new POJO MicroContainer] - Re: Lifecycle aspects revisited
by kabir.khan＠jboss.com
http://jira.jboss.com/jira/browse/JBMICROCONT-154
I should be ready to commit something later today - question is to which branch?
What we have is a new LifecycleCallbackMetaData which gets populated by the DescribeAction + AOPDependencyBuilder. It does not really use AOP much for anything other than the matching of the classes pointcuts. These lifecycle callbacks are then added to the BeanMetaData.
I've modified KernelControllerContextAction install/uninstall to look for lifecycle callback metadata and if this exists to invoke the callbacks.
It is configured as follows
| <aop:lifecycle-configure xmlns:aop="urn:jboss:aop-beans:1.0"
| name="DependencyAdvice"
| class="org.jboss.aop.microcontainer.aspects.jmx.JMXLifecycleCallback"
| classes="@org.jboss.aop.microcontainer.aspects.jmx.JMX">
| <property name="mbeanServer"><inject bean="MBeanServer"/></property>
| </aop:lifecycle-configure>
|
Which translates to
| <bean name="DependencyAdvice" class="org.jboss.aop.microcontainer.aspects.jmx.JMXLifecycleCallback">
| <property name="mbeanServer"><inject bean="MBeanServer"/></property>
| </bean>
|
| <bean name="DependencyAdvice$Binding" class="org.jboss.aop.microcontainer.beans.LifecycleBinding">
| <property name="callbackBean">DependencyAdvice</property>
| <property name="manager"><inject bean="AspectManager"/></property>
| <property name="classes">@org.jboss.aop.microcontainer.aspects.jmx.JMX</property>
| <property name="state">Configured</property>
| </bean>
|
|
The callbacks are no longer "interceptors", so there is no chain, and by default it will look for methods called install and uninstall. Callback methods must take the KernelControllerContext as a parameter:
| public class JMXLifecycleCallback
| {
| private MBeanServer server;
|
| public void setMbeanServer(MBeanServer server)
| {
| this.server = server;
| }
|
| public void install(KernelControllerContext context) throws Exception
| {
| JMX jmx = readJmxAnnotation(context);
| ObjectName objectName = createObjectName(context, jmx);
|
| //register in jmx
| }
|
| public void uninstall(KernelControllerContext context) throws Exception
| {
| JMX jmx = readJmxAnnotation(context);
| ObjectName objectName = createObjectName(context, jmx);
|
| //unregister in jmx
| }
|
| private JMX readJmxAnnotation(KernelControllerContext context) throws Exception
| {
| if (context.getMetaData() != null)
| {
| return context.getMetaData().getAnnotation(JMX.class);
| }
| return null;
| }
|
| private ObjectName createObjectName(KernelControllerContext context, JMX jmx) throws Exception
| {
| ...
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025364#4025364
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4025364
19 years, 1 month