Why is MessageSourceServiceImpl transactional?

I’m running into a bug with the UI framework where if i submit a form and i get sent back to the form with validation errors, the changes i made get persisted to the DB (premature hibernate flushes), after some debugging i figured out the cause of this was due to the fact that MessageSourceServiceImpl is transactional, spring will attempt a flush on returning from any transactional method where readOnly attribute is not set to true:

How is this related to the ui framework and the bug i was running into? Because when the form has validation errors, the field error widget in uicommons module calls a method in MessageSourceServiceImpl to translate the error codes that doesn’t have readOnly set to true therefore the changes always gets flushed to the DB. I believe MessageSourceServiceImpl shouldn’t be transactional in the first place since it doesn’t have any DAO interaction. I will go ahead and create a ticket to fix this unless some one thinks otherwise.

MutableMessageSource is marked as transactional as well:

I don’t see where MessageSourceService or MutableMessageSource use the database. They seem to be working with hashes in memory. So, unless someone can enlighten us, I would think you should remove @Transactional from both classes.

Generally sounds good to me… however, maybe it should stay @Transactional but readOnly=true? Doesn’t the custom messaging module register a custom message handler (which I assume would still be accessed through the message source service) which pulls messages from a new DB table it creates?

1 Like

That is interesting Mark, I’m not sure how the custom messaging module works, does it register a custom MessageSource and configures it as the activeMessageSource in MessageSourceServiceImpl?

I have created a JIRA issue to address this:

Not 100% sure, but I believe so. @mseaton knows more.

Yes, see the “setApplicationContext” method on this class:

1 Like

Looks like we need to update CustomMessageServiceImpl to make the get methods readOnly too, but this worries me that someone else might later register a new message source and carelessly introduce the same issue, i believe our code convention is that getters in the service layer should always be readOnly and we should try to enforce it when reviewing code.