JIRA will deadlock when trying to get the next block of sequence numbers for a database id under some rare but reproducible circumstances.

This was discovered during development testing of the JIRA Archiver, to the best of our knowledge it has not been seen in the wild.

The specific case discovered was when a remote application concurrently sending requests to create remote issue links on 10 threads and JIRA was using the DBCP connection limit default settings of maxActive (connections) = 8. This would cause JIRA to totally deadlock

Our, somewhat imperfect, understanding from examining the thread dumps from this scenario is that:

• 10 requests would arrive and each begin to add a remote link, taking a connection from the connection pool to do so.
• At some point one thread would cause the sequence generator to require new block of sequences
• The sequence generator would request a new connection from the pool.
• The remaining threads would block at SequenceUtil.SequenceBank.getNextSeqId(), which is a synchronised method
• At this stage all threads would start to march in lock step
• The threads would then move to writing a change history group and each would request a connection from the pool, not all would get a connection and some would be waiting. We will call those that aquired a connection threads 'A' to 'H'. Threads 'I' and 'J' would be waiting.
• Thread 'A' would then require a sequence number calling SequenceUtil.SequenceBank.getNextSeqId() and needing to get a new block of ids would then request a connection from the pool to do so (It needs a new connection to do this so it is not in the transaction of the calling thread)
• Threads 'B' to 'H" are all now waiting on the syncronisation lock of SequenceUtil.SequenceBank.getNextSeqId() which is held by thread 'A' and so will never release a connection for thread 'A' to use.
• DEADLOCK