Fix #6124 Permissions lost when doing something transactional in the … #6127
Conversation
… in the afterCommit handler of a Job
| } | ||
| else | ||
| { | ||
| return doCallInTransaction(); |
There was a problem hiding this comment.
Are we actually doing the call in a transaction here? I'm a bit confused
There was a problem hiding this comment.
The Jobs run running on a separate executor thread.
If we do nothing, it will run without permissions and not in a transaction.
It is no bean so annotating the call() method with @transactional won't do anything.
So we need to manually set the permissions and manually call the TransactionTemplate.
This PR turns the order inside out.
Call the transaction template within the user switch.
Used to be switch the user within the transaction.
The bug was that the afterCommit then runs after the permissions get restored/removed.
There was a problem hiding this comment.
Or do you mean the case where no transaction template is specified? There we don't run in a transaction.
…afterCommit handler of a Job
The idea is to turn the order around, do the permission switch outside the transaction instead of the other way around.
Before:
After:
Checklist