bug #8066
closedCdmUserHelper.createAuthorityFor() causes flush of pending transactions
100%
Description
This was observed when testing for regressions related to #8039, the following steps where done in the registration UI
- add "existing name" to registration workingset
- add NameTypeDesignation
- create new "Typified Name"
- Save NameTypeDesignationPopupEditor
during the save operation a PermissionDeniedException occurred:
[reference_int] 12:10:42,124 ERROR [qtp93314457-353][eu.et.va.mv.AbstractPopupEditor] - eu.etaxonomy.cdm.database.PermissionDeniedException: [CREATE] not permitted for 'system-admin' on Registration[uuid:5920ff17-ff73-4930-acb7-3a5d2d906279', toString:'Registration#42<5920ff17-ff73-4930-acb7-3a5d2d906279>']
this was caused by a flush on dirty in the CdmUserHelper.createAuthorityFor() method
Updated by Andreas Kohlbecker over 5 years ago
- Description updated (diff)
A forced flush before changing the authentication should help in this case. Other options are to
- do the authority creation in a separate transaction which would involve to use a different transaction isolation level.
- use a temporary sub-session like in
eu.etaxonomy.cdm.persistence.hibernate.GrantedAuthorityRevokingRegistrationUpdateLister.deleteAuthorities()
Updated by Andreas Kohlbecker over 5 years ago
Using the PROPAGATION_REQUIRES_NEW turned out to be in-appropriate. It was causing LazyInitializationExceptions, the same would be the case with temporary sub-sessions. In both cases it would be needed to reload cdm entity into the new session to avoid the LazyInitializationExceptions
Doing an explicit flush seems to be a good solution to the problem.
Updated by Andreas Kohlbecker over 5 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 50
Applied in changeset cdmlib|4c2a3c2cc8e7583d613dd5e24afc5fdda3442816.
Updated by Andreas Kohlbecker over 5 years ago
- Status changed from Resolved to Closed
- % Done changed from 50 to 100