-
Bug
-
Resolution: Fixed
-
Medium
-
4.3, 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.4, 4.4.1, 4.4.3
-
Windows & all flavours of Linux, tested on databases: Oracle, MySQL, Postgres
-
4.03
-
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).
- is caused by
-
JRASERVER-26227 The storeAll method in OfBiz always runs in the ExplcitCommitSqlProcessor, however if you call this with no transaction scope, a new transaction is not always started.
- Closed
- is related to
-
JRASERVER-26321 JIRA in Windows not shutting down the plugin system at the end of the build
- Closed
-
JRASERVER-34376 Issues not committed to database (and cannot be fetched) at time of event dispatch for issues created from post function
- Gathering Impact
- copied to
-
JRADEV-8684 Loading...
- mentioned in
-
Page Loading...