jBPM and clustering

[bpoweski]

Is jBPM cluster safe?

Specifically can I run 2 or more applications utilizing the same jBPM database?

What abou timers?

-b

[sforema]

State is saved in the database, so you should be fine in a cluster. I would not allow a single process instance to run across clusters (which could theortically happen in a fork).

Someone else can answer the timer question. I believe timers (SchedulerThread.java?) are implemented using threads, which is interesting since threads are a no-no in a J2EE environment ;-)

[kukeltje]

not completely. Threads seem to be allowed from within a servletcontainer, although nobody ever showed me the proof.

[ralfoeldi]

Hi Sean,

nice to see you back. I almost thought you'd left us :-)

Ronald:
Thread spawning is discouraged in the Servlet container, not forbidden (but I would have to check the specs for that.) Websphere for one logs nasty warning and 'NoNo' statements that alarm the admin guides but lets everything pass.

'b':
Clustering doesn't pose any specific problems. You will just have to handle the same concurrency issues as you would in a single JVM.

Timers are a different matter. There are one or two Jira issues and a few threads here on that matter. You will almost ceratinly run into trouble if you have two or more SchedulerServlets running.

Greetings

Rainer

[sforema]

Me leave? Nah. I'm like a bad penny.

You don't even want to see my NodePersist class. That breaks all the rules ;-)

Ltr

Sean

[ralfoeldi]

Sean,

don't post it. There are minors in this forum ... and I probably would only get stomach aches :-)

Rainer

[sforema]

Very nice. You'll only find NodePersist in dark alleys alongside stolen watches.

I'm actually very happy with it along with ForkAsync and JoinAsync. I can run a query and know exactly what nodes a process is in. The query returns one row for each token with its status and restart info if it fails. And the process flow definition isn't cluttered with any extra nodes or code to make asynch stuff work...

I will be putting a symaphore in shortly to prevent a race condition and then it should be solid as a rock.

Ya know, when I think of someone coding in switzerland, I imagine a cabin out in the woods at the base of a moutain with the fireplace going and wireless access. I don't want to know about the dreary cubicle you are actually in. I prefer the cabin vision.

Ltr,

Sean

[ralfoeldi]

Sean,

you'd really want to know, eh? Well I'll leave it to you to figure out which version's a dream and which not :-) (Don't forget that Koen is a blonde d-cup... + fireplace, + cabin.... oh well... Koen isn't here, was just an idea.)

And concerning your fork stuff. If you know what you're doing and it works: great. I just don't know that many people that truely know what they're doing when it comes to transactions and concurrency - sometimes I get a bit confused myself, at least for a short time.

Your solution just wouldn't work for me - and probably others - because the scope of the transactions is too small and because of that threading thing...

Now... I got take care of the fireplace :-)

Rainer

[koen.aers]

OK the blonde D-cup with an answer ;-)

Jbpm is custerable for examble by using it with a clusterable session facade. As stated somewhere in this thread, you *have* to lock the processinstance (either pessimistically or optimistically) while signalling one of more concurrent paths of execution.

Regards,
Koen

[bpoweski]

Awesome, thanks for the info!

I'm still trying to wrap my head around exactly how we want to leverage this product in our enterprising. I believe the approach we want to take is focus more on letting jBPM coordinate process than actually doing all of the heavy lifting.

[arshadnj]

Good information about clustering!

The Thread says, we will run into trouble if we run two or more scheduler servlets. If this is the case, how will take care of fail-over of Timer's in a clustered environment?

Thanks,
Arshad