Refactor SprintCustomFieldManagerImpl to use more fine-grained locking

Summary

Every load of the Rapid Boards retrieves the sprint custom field ID from the database. The way the code is structured is such that the method used to retrieve the data is synchronised - this means any latency on that retrieval can cause significant thread congestion, presenting in an instance appearing to be unresponsive or experiencing performance problems.

Steps to Reproduce

Load the rapid view board under high load.

Expected Results

The board consistently loads without error.

Actual Results

One of the database retrieval operations may take some time to complete, if this occurs congestion can apply to a number of threads. In worse-case 10 to 100s of threads may block waiting for the operation to complete.

Verification

Review the thread dumps to verify if there is congestion on the com.atlassian.greenhopper.service.sprint.SprintCustomFieldServiceImpl monitor, specifically there are a number of threads waiting for it as per the attached screenshot. They can also be analysed with the following:

grep "waiting to lock.*SprintCustomFieldServiceImpl" jira_threads* | awk '{print $1}' |sort |uniq -c
   1 jira_threads.1424257020.txt:
  42 jira_threads.1424689917.txt:

In jira_threads.1424689917.txt we can see 42 threads are waiting - this would imply that thread dump is affected with that problem.

Notes

Upgrading to JIRA 6.2 or higher has been known to improve the problem.