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

0 votes
Accepted answer


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 Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,737 views 17 21
Read article

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