Recently we have stumbled upon a serious problem with locks appearing on our jira database.
After investigation it came out that locks on the database are generated (in)directly by Kepler's Datatable custom field.
For those who don't like to read, just skip the detailed description of problem.
Custom field had a simple select to Jira's own database (yet configured as a JNDI source) display all (~65) issues of one type. Used database account had only read rights.
What's more important the custom field was used only for less than hour, and then removed from any screens. It was not displayed anywhere. Even though, it was executing by itself on the database and getting locked soon after, causing a further avalanche of locks resulting in disabling Jira in less then half an hour.
Turning off the account that Kepler used to connect to the database seemed to solve the problem (but in the same time disabled all our extremely useful Database Custom Fields). If the account had been turned back on, it took 5-10 minutes to execute the query by itself again causing locks again.
After deleting the query from Kepler dataTABLE CF and deleting the custom field in Jira everything went back to normal and we were again able to use our dataBASE custom fields without any problems.
The problem seems solved, but it is merely a band-aid solution. I don't truly understand what was the cause, and it's bugging me. I feel like we nuked the whole city just because one citizen was sick and we couldn't tell which one.
Thread local caching has been set to "True" in the Kepler's CF configuration. Was this the cause? What exactly does that parameter do?
Why the query of the field was executing on the database by itself even if the field was not used on any screens?
I will appreciate any help. Especially because Kepler's fields are really awesome and extremely useful. We want to use the datatable field in future but for now we are simply afraid, that we might not fully understand how it works.
We should investigate this, but in that case we'll need more input. Please open up a case on our JIRA (http://bugs.kepler-rominfo.com/) and tell us:
1/ exact configuration (SQLs)
2/ What database are you using, isolation level.
3/ version(s) used. We're interested in katl-commons, dbcf, kcf versions
From what I've checked, we really close statements / db connections on finally ;) so from the pure JDBC perspective we should not have any problem.
Thread local caching has nothing to do with the issue you encounter. It is a parameter that prevents re-evaluation of the scripted fields, as you have noticed, re-evaluation of the fields (of any field), happens more than once in JIRA.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot