1) If you're on JBoss build a MDB and let that start your process - maybe storing your document before.
2) If you use a MDB you will by default be load balancing. Every MDB has one thread and processes one message at at time. Configure 5 MDBs, you get 5 threads. Add 4 Servers and you have 25 threads. As simple as that. As the execution of every process would happen in the thread of the MDB you wouldn't have any synch problems... unless you splitt up your process, have wait states and restart etc. Then you would have to lock on the processInstance.
Performance? Great. Above szanrio is in production at a large Swiss insurance company processing up to 1 Mio messages a day.
Freeting from bern
Thanks a lot for your reply. Nice and simple solution. And as long as it's simple it should be robust :)
The only thing here is as far as I remember jboss does not support clustering for MDB, or at least did not support it in version 3.2.3 which we got in production by the time. The point is we use Oracle DB as a persistent storage for JMS queues and jBPM processes and I'm afraid there'll be synchronization problems when two or more instances of jboss are trying to fetch the next message from the queue that is persisted in the same Oracle table. In fact I tryed something similar. There were two jboss servers and a queue persisted in a DB table. When I issued lookup query from both jboss simultaneously they both got inconsistent and reported invalid queue state.
Has this feature been improved since 3.2.3?
Have a look at the new JBoss Messaging product.