Getting scalability with jBPM running on JBoss can require the use of clustered hardware. If you need to grow a jBPM configuration, Szymon Zeslawski explains in detail how to cluster jBPM efficiently - from cluster setup to fine-tuning jBPM configuration, and provides performance test results and various tips and tricks allowing to achieve maximum performance. Read article

Is the link missing?

working now.

Szymon, in order to achieve a scalable system our team decided to tweak JBPM in another way: not to use a classic distributed cluster at all. We use a farm of non-clustered servers each with a local cache. Starting off a new job works in our case as the JBMP default by firing a JMS message away when there is a runnable job in the db. However, we tweaked asynchronous job execution in a process-instance that way, that it stucks on the local machine by using threads from a pool.

It would be nice to see workflow products ditch the database for storing and scheduling jobs. You can't scale up if the database doesn't, and no, I shouldn't have to buy Oracle.

I'm worried about the use of asynchronous replication for entity beans since it does not guarantee data consistency accross the clusters. Entities are not generally accessed on a sticky manner, hence, updates can happen in multiple nodes in parallel. Having REPL_ASYNC for entity cache means that you cannot guarantee the outcome of two parallel updates to the 2nd level cache coming from different nodes. You can get away with REPL_ASYNC in sticky scenarios such as http session replication where you can get a session to be accessed on a single node at the time and only use another node in a failure situation. You should be using REPL_SYNC for your 2nd level cache.

You are obviously right, it's typo, SYNC should be used for entities. Thanks for pointing this out. I'm just wondering whether INVALIDATION_SYNC would give better performance than REPL_SYNC? In my tests I couldn't show a significant difference...

First of all, excellent post. I am just curious to know one thing though, why you have used JobExecutor and not JMS based async job processing? Any insights into this decision, and advantages from performance perspective would be really helpful.?