Is it safe to use JiraPluginSettings in clustered environment?
If not, how to store plugin settings (changed infrequently) in a safe way?
@Chris Fuller, you are probably the best person to ask.
Thank you,
Gebsun
Community moderators have prevented the ability to post new answers.
No. And it's such a terrible interface, I'm not sure why you would want to, anyway.
The list of what's wrong with PluginSettings
is a long one, but here's a small taste:
IllegalArgumentException
), or you can stick it in the global settings with a prefix. This global namespace is exactly the same one that ApplicationProperties
uses, but the encoding of the data is slightly different, so they pollute each other's namespaces with differently encoded information. Awesome.PropertySet
, which you could use directly if you wanted to. Of course, that itself is a rather nasty beast that splits its information across multiple tables. It has the main table for entries and each data type (number, string, text = strings greater than 255 chars, date, etc.) goes to a different table. This has its advantages, but efficiency and atomic updates aren't on that list. You can't do updates to that safely without a cluster lock, so the same is true of PluginSettings.I could go on, but look, please just no.
PluginSettings
really has no point in existing at all except that Cloud (called Studio at the time) needed some storage mechanism that cross-product plugins like Applinks could use before we had Active Objects available to answer that question. Even though it has its own set of problems, AO is at least an improvement over PluginSettings
.
The strategy that Atlassian's own JIRA plugins are using for this is to use AO to describe the schema management, but the more flexible PocketKnife QueryDSL library to do the actual data manipulation, as it can do all the things like optimistic updates that you really need to achieve cluster safety and still keep your sanity. It isn't perfect (for example, AO can't declare multi-column indexes and blows up trying to remove any that you added yourself), but I think that this is the best answer we currently have available to us.
You are guru and that's not flattery :-).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Excellent and clear answer. Thank you. I believe Atlassian should invest into documentation more. PluginSettings are still marketed all around in docs, e.g.: https://developer.atlassian.com/docs/common-coding-tasks/storing-plugin-settings https://developer.atlassian.com/docs/getting-started/learn-the-development-platform-by-example/store-and-retrieve-plugin-data
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Fair cop. Unfortunately, these search-and-destroy missions are always a bit difficult and our first line of defense as developers is always to mark the old way as deprecated. Nobody has actually gotten around to doing that to PluginSettings, yet. Also, those tutorials aren't aimed at JIRA Data Center compatibility in particular; they're just a quick and dirty getting started guide. There are more comprehensive instructions for JDC here: https://developer.atlassian.com/jiradev/jira-platform/jira-data-center/plugin-guide-to-jira-high-availability-and-clustering (although, sadly, they don't talk about plugin data storage in particular, either)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.