We are regularly but not reliably encountering this problem when a user attempts to initiate a workflow transition. The stack trace in the log is quite lengthy but starts out like so:
2012-02-02 11:36:41,473 http-8080-10 ERROR BarnetJA 695x21691x8 ve2g0a 165.127.154.34 /secure/CommentAssignIssue.jspa [atlassian.jira.workflow.OSWorkflowManager] Caught exception while attempting to perform action 41 from workflow 10251 on issue 'GEN-24'
com.opensymphony.workflow.StoreException: Error marking step #11108 finished: root cause: while updating: [GenericEntity:OSCurrentStep][caller,BarnetJA][id,11108][startDate,2012-02-02 11:23:07.0][status,Not Done][owner,][finishDate,2012-02-02 11:35:50.363][actionId,41][stepId,4][dueDate,null][entryId,10251] (SQL Exception while executing the following:UPDATE OS_CURRENTSTEP SET ENTRY_ID=?, STEP_ID=?, ACTION_ID=?, OWNER=?, START_DATE=?, DUE_DATE=?, FINISH_DATE=?, STATUS=?, CALLER=? WHERE ID=? (Lock wait timeout exceeded; try restarting transaction))
at com.opensymphony.workflow.spi.ofbiz.OfbizWorkflowStore.markFinished(OfbizWorkflowStore.java:241)
at com.opensymphony.workflow.AbstractWorkflow.createNewCurrentStep(AbstractWorkflow.java:1473)
at com.opensymphony.workflow.AbstractWorkflow.transitionWorkflow(AbstractWorkflow.java:1256)
at com.opensymphony.workflow.AbstractWorkflow.doAction(AbstractWorkflow.java:567)
at com.atlassian.jira.workflow.OSWorkflowManager.doWorkflowActionInsideTxn(OSWorkflowManager.java:905)
at com.atlassian.jira.workflow.OSWorkflowManager.doWorkflowAction(OSWorkflowManager.java:865)
at com.atlassian.jira.bc.issue.DefaultIssueService.transition(DefaultIssueService.java:505)
at com.atlassian.jira.bc.issue.DefaultIssueService.transition(DefaultIssueService.java:513)
at com.atlassian.jira.web.action.issue.CommentAssignIssue.doExecute(CommentAssignIssue.java:197)
at webwork.action.ActionSupport.execute(ActionSupport.java:165)
at com.atlassian.jira.action.JiraActionSupport.execute(JiraActionSupport.java:76)
This seems to me to be a Jira internal problem - why would that row be locked for so long? However, I don't see any evidence that other Jira installations have encountered this problem, which suggests that it could be specific to our database setup (mysql 5.1.44, Jira 4.4.4).
I'd appreciate any ideas about how to fix this.