Kepler datatable custom field - Thread local cahing and database locks


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.

Best Regards,

Blazej Olszyca

1 answer

1 accepted


We should investigate this, but in that case we'll need more input. Please open up a case on our JIRA ( 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.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,803 views 11 18
Join discussion

Atlassian User Groups

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!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot