Creating an issue from a transition can lock the database under load.

vCalling Jira's create issue routine from any transition locks the database.
The workflow advances an issue in the workflow and on the executed transition it creates another issue by calling Jira's own create issue code.

The attached test case locks Jira each time.
Steps to reproduce:
1. Install the bic plugin (it's a type 2 plugin) - Please see the README.txt found in the sources archive
2. Create a workflow scheme "WF-SCHEME-STRESS-TEST"
3. Create transition "Create other issue" and set the issue creation postfunction on this transition
4. Start JMeter and load the stress test project.
5. Execute it.

You can easily import in a JIRA instance the xml dump we used for test (jira_4.3.4_lock_problem.zip).

Output with the problem:
(SQL Exception while executing the following:UPDATE project SET pcounter=? WHERE ID=? (Lock wait timeout exceeded; try restarting transaction))
at org.ofbiz.core.entity.GenericDAO.singleUpdate(GenericDAO.java:253)
at org.ofbiz.core.entity.GenericDAO.singleStore(GenericDAO.java:300)
at org.ofbiz.core.entity.GenericDAO.storeAll(GenericDAO.java:318)
at org.ofbiz.core.entity.GenericHelperDAO.storeAll(GenericHelperDAO.java:221)
................................

Related to: support issues: JSP-93481 and JSP-93314

Note 1: Our temporary workaround was to create the issue on another thread. However, I cannot wait for that thread to finish in the original post-function because I will run into the same problem. On the other hand, I also cannot always create the issue independently because I will need its id in the 'originating' issue for further processing.
Note 2: Please do not say it's our fault (unless we have made a HUGE mistake ). To preserve consistency, I must use your API, so I'm kinda constrained to it (I do not want to go directly on the database). Please notify us if you think your API is not used correctly.
Note 3: IMHO, the update "UPDATE project SET pcounter=? WHERE ID=?" can be avoided. This will boost a bit the performance at issue creation. Use the reservation technique, similar with what Oracle does on sequences. In this matter, you are already greatly helped by the fact that you cannot cluster Jira (but a similar solution should be used when you finally decide to make it cluster aware).