1. Sign in as admin
2. Go to Administration, Server Configuration
3. Press Save
A significant amount of errors show on the console. These don't seem to have an effect on saving the values given in the fields, but the impact is otherwise unknown.
Also, in org.zanata.ApplicationConfiguration#resetConfigValue you have it purge the config value from databaseBackedConfig and jndiBackedConfig. Since Zanata doesn't ever change values in JNDI, perhaps we don't need to purge jndiBackedConfig (and thus JndiBackedConfig wouldn't need a transactional cache)?
(Incidentally I think part of the reason we originally used JNDI was to allow the possibility of sysadmins changing bindings at runtime via JBoss management features, but I don't think EAP/WildFly has any mechanism for notifying apps that a JNDI binding has changed.)
Yes, so as you might have seen this are might use a bit of cleaning, specially now that JNDI config is gone. I think we should stop using events for this, take a more coupled approach, and stop worrying about transactions and race conditions. Also, caching is good for the DB, but I think hibernate might already be giving us that. Not sure if caching gives us something extra for System properties but we could implement something there.
I don't think caching would gain us anything (except complexity) for system properties, and I agree that we should let Hibernate do the transactional caching.
As long as we fetch the values from Hibernate/its transactional cache/the database every time, we won't need to worry about transactions to achieve correctness.
(Although we will still need to add @Transactional to RateLimitManager#configurationChanged to eliminate the error encountered.)
I think it still makes sense to decouple ApplicationConfiguration and RateLimitManager using the ConfigurationChanged event though.
Verified in RC2