Simultaneous process creation and execution

[j_p_ryan]

Hi,

Our plan is to use Activiti embedded within our application.  One piece of functionality that we are looking to build is where a manager will have the option of creating say 100 pieces of work for his/her staff.  In effect the manager will enter 100 customer numbers on a screen that a team of people, which work for the manager, should contact.  The process of contacting the customers will involve both human and automated tasks.  This will imply that 100 new process instances of the “contact customer” process will be created when the manager submits the form with the list of customer numbers.

- Any concerns around creating 100 process instances “in one go”?
- If the first task of the process is an automated task (e.g. calls a piece of Java, Web Service etc.) how are the threads managed?  Might 100 threads all kick off at once?
- What other things should I be concerned about?

Thanks,
James

[ronald_van_kuij]

- what is one go? One transaction? Is not a problem if the first task is a 'user task' or something short, not a 1h db run…
- Nope, that is sequential, unless you create 100 threads yourself.
- Be concerned about things you would otherwise be conserned about as well… 🙂

[j_p_ryan]

Hi Ronald,

Thanks for the response.  Theoretical (for now at least) follow up:

Assume that “one go” is a single transaction (we must create the processes for the 100 customers or not at all) and that the first task in the process is a Java call.  The task takes 5 seconds to complete for each customer with the task having some side effect (e.g. DB update).  I believe that this implies that the transaction will be open for 100 * 5 seconds plus the Activiti Engine time.  500+ seconds for a single transaction seems a bit "dangerous" considering DB locks, concurrency and the like.

Just looking for some pointers on how one might proceed if the theory became a reality.

Am I right in assuming that if the first task in the process is a human task then there is no real issue in terms of the length of the transaction (i.e. it should take “a few seconds” (ignore hardware, DB etc.) to do the Activiti inserts etc. to set up the process) as Activiti will just go into a wait sate?

Thanks,
James

[ronald_van_kuij]

500+ seconds for a single transaction seems a bit "dangerous" considering DB locks, concurrency and the like.

Correct

Am I right in assuming that if the first task in the process is a human task then there is no real issue in terms of the length of the transaction (i.e. it should take “a few seconds” (ignore hardware, DB etc.) to do the Activiti inserts etc. to set up the process) as Activiti will just go into a wait sate?

Correct

What you should investigate (in any case) is why could starting one of the 100 instances fail and there are other options.

E.g. to split it into individual starts and have a retry on each one that failed by e.g. giving a process instance a business key and looking up in a retry (e.g. if it was from a batch file) if a process with a specific businesskey already exists. But creating parallel threads yourself, e.g. 10, and having all of them use the same transaction (not sure how to do that :-)) could be an option to reduce time… or…. Basically, this is not specific to Activiti, but more generic problem 🙂

[j_p_ryan]

Hi Ronald,

I guess what you are suggesting is to make the creation of the business process instance idempotent.  Sounds like a possible use for an aspect (AOP).

Would certainly agree that all the usual design challenges will exist around race conditions, what happens if it is valid to have >1 business process for a customer etc.

I might be back to you if the theory becomes a reality for some more Activiti specific guidance!

Thanks for your help,
James

[ronald_van_kuij]

Correct and if you make sure the businesskey is unique, the engine will already fail starting another one with the identical key