Details
-
Enhancement
-
Resolution: Done
-
Major
-
7.11.0.Final
-
NEW
-
NEW
Description
When a user belongs to many groups, UserGroupCallbackTaskCommand.doCallbackGroupsOperation() could be a bottle-neck because it loops over all groups and calls context.getPersistenceContext().findGroup(groupId).
https://github.com/kiegroup/jbpm/blob/master/jbpm-human-task/jbpm-human-task-core/src/main/java/org/jbpm/services/task/commands/UserGroupCallbackTaskCommand.java#L164-L169
https://github.com/kiegroup/jbpm/blob/master/jbpm-human-task/jbpm-human-task-core/src/main/java/org/jbpm/services/task/commands/UserGroupCallbackTaskCommand.java#L174-L176
https://github.com/kiegroup/jbpm/blob/master/jbpm-human-task/jbpm-human-task-core/src/main/java/org/jbpm/services/task/commands/UserGroupCallbackTaskCommand.java#L195
Kris wrote:
we could try to implement TaskPersistenceContext.findGroups(..) to be able to pass a large number of ids in one call (and then later check which ones are all in there).
Maciej wrote:
I wouldn’t go for this as it will have rather significant code changes - mainly as right now code does not considerer multiple groups. In addition the use of IN ins SQL has usually limitations on some dbs and thus can become problematic. Instead I would recommend to configure cache for users and groups - that in general makes a lot of sense so with that we avoid db roundtrip for every check and we just check the cache which should dramatically improve performance in this use case
Attachments
Issue Links
- is incorporated by
-
-
- Closed
-
